How to initialize a char*?

[Peter]

Hi,

So many times, I have seen compile warning: "you used a char* without
initilize it", probably on the code like this:

------------
char* ptr;

func(..., ptr);
----------

How to properly initialize a char*? I used to use

char* ptr = "";

but was told this is not good.

Can anybody explain to me why, and what's a good way to initilize it?

Thanks,
Peter

[Christopher Benson-Manica]

David Harmon <so****@netcom.com> spoke thus:

If so, it is an evil func. You can tell me which fatal error does it
have, buffer overflow, or thread-hostile static buffer, or dynamically
allocating memory that the caller will forget to free? It needs to be
rewritten to use std::string.

The point of all this pedantry was merely to identify what is legal,
not what is good practice.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Old Wolf]

"Peter" <yb***@yahoo.com> wrote:

So many times, I have seen compile warning: "you used a char* without
initilize it",
This is the compiler being nice by telling you you have probably made
a logic error in your program. You should fix your program, instead of
trying to shut the compiler up.
probably on the code like this:

------------
char* ptr;

func(..., ptr);
And indeed you have made a logic error. I'm not quite sure how to
describe the nature of this error, other than to say "you used a
variable without initializing it". So obviously func() is not going
to do what you wanted (unless it ignores that parameter).
How to properly initialize a char*?
Well that question doesn't really make sense. It depends what func()
is expecting. Let me replace your example by a more well-known function:

char *ptr;
puts(ptr);

To "properly" initialize ptr in this example, you would have to point
it to a string. Making it a null pointer (as some others have suggested)
would not be an improvement.
I used to use
char* ptr = "";
but was told this is not good.
Can anybody explain to me why, and what's a good way to initilize it?

Why does the variable even exist in the first place?
Once you have answered that question, then you know what its value
should be.

Note that other people on this thread have said that you must initialize
variables to something, before you get up to the bit where you put them
to their intended use. This is in fact a matter of coding style;
personally I think such initializations are a waste of time (coding time,
run time, and maintenance time), and only serve to hide logic errors
that might be revealed by the warning "use of uninitialized variable".
You should do whatever seems right to you.

[Kevin Goodsell]

Ioannis Vranos wrote:

Check this out:
#include <iostream>
int main()
{
using namespace std;

char array[]="12345";

*array='X';

cout<<array<<endl;
}

I'm not sure what your point is here... But I'm afraid Julie is correct.
References to pointers are fine, and your example code demonstrated a
problem because you passed an incompatible type. Try it again like this:

void func(char * const input, int word_number, char * & ptr_to_word)
{
}
int main()
{
char array[]="b";
char *p = array;
func("a",5, p); // pass a pointer, not an array
}

I think you are hinting at the usual conversion ("decay") of an array
name to a pointer. It doesn't apply when binding to a reference.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Ioannis Vranos wrote:

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:c5**********@chessie.cirr.com...

Peter <yb***@yahoo.com> spoke thus:

char* ptr;
func(..., ptr);
This is bad - ptr is uninitialized (not even NULL), so passing it to a
function is either pointless or an invitation to disaster, a mistake
in any case.

Why?

Assuming ptr is being passed by value, the behavior is undefined. You
are generally only allowed to do a few things with an uninitialized
variable. For example, you can assign to it, take its address, bind it
to a reference, apply 'sizeof' to it, etc. However, inspecting the value
(as must be done to make a copy when passing to a function) is not
permitted.

The technical details of this are described in the standard in the
section about converting from a lvalue to an rvalue, if I recall
correctly. Essentially, this conversion is not defined for an
uninitialized lvalue.

How to properly initialize a char*? I used to use

char* ptr = "";

Depends on what you're doing with it. You probably were told that
because it should be

const char *ptr="";

And what would be the use of that?

You should not assign a string literal to a non-const char pointer. This
is a deprecated and dangerous conversion, included for C compatibility.
In both languages it is dangerous. In C++, the type of a string literal
is 'const char[N]' where N is chosen to be the appropriate size. The
conversion to (non-const) char* is permitted, but breaks
const-correctness and allows code that attempts to modify a
const-object, causing undefined behavior.

Why? Because "" is a constant empty string; trying to modify it
invites disaster. Therefore, pointers to such string literals (so
they're called) should be declared const; that way if you try to
modify what it points to the compiler can inform you of your mistake.

The above is entirely, completely useless.

I don't understand why you think it is useless. If your point is that
the assignment itself is wrong, you may be right. We don't know what
he's doing, but it seems likely that pointing to a string literal is not
useful (particularly when it is done only to silence a warning).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Ioannis Vranos wrote:

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:s_*****************@newsread1.news.pas.earthl ink.net...

This uses a dangerous and deprecated language feature -- the implicit
conversion of a string literal to a (non-const) char*. I'd suggest
making your compiler warn about this if it provides such a warning.

Eh?

I'd be happy to clarify if you'll tell me which part you have a problem
with. I did already go over this in a bit more detail elsewhere in the
thread (in another reply to you, I believe), so you might check there first.

If you want to check the standard you can find this in D.4
[depr.string]. There's also information in 4.2/2 [conv.array]. Finally,
2.13.4 explicitly states that string literals consist of const
characters, and I know it's stated somewhere that modifying const
objects gives undefined behavior, but I'm not sure where to look.

Initialize it with whatever you need. You're the only one who knows what
purpose it serves, so we can't suggest what to use. But leaving it
uninitialized is an error, and doesn't make sense.

It is not an error!

Failing to initialize in itself is not an error. But using the
uninitialized value is undefined behavior.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Kevin Goodsell wrote:

I don't understand why you think it is useless. If your point is that
the assignment itself is wrong, you may be right.

Should be "the initialization itself". And judging from your other
replies, I guess this is what you meant. The initialization to an
arbitrary string literal is probably not useful.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Gary Labowitz]

"Buster" <no***@nowhere.com> wrote in message
news:c5**********@newsg1.svr.pol.co.uk...

Sam Holden wrote:

>
>Iannis Vranos <iv*@guesswh.at.emails.ru> wrote:

But this doesn't compile:

void f (char * &) { }

int main ()
{
char c;
f (&c);
}

<<snip>>
And after all the smoke clears we find ...

#include <iostream>
using namespace std;

int main( )
{
void change(const char*, char* &);

char s[10]= {"x"};
char* ptr = &s[0];
cout << "content of pointer is " << ptr << endl;
change("ABC", ptr);
cout << "content of pointer is " << ptr << endl;
return 0;
}

void change(const char* nus, char* &nup)
{
strcpy(nup, nus);
return;
}

--
Gary

[Buster]

Gary Labowitz wrote:

And after all the smoke clears we find ...

[snip]

Maybe you shouldn't smoke that stuff during the week.

#include <ostream>
#include <iostream>

void redirect (char const * & reference, char const * pointer)
{ reference = pointer; }

int main ()
{
char const * p = "Hello.\n";
redirect (p, "Goodbye.\n");
std::cout << p;
}

--
Regards,
Buster.

[Christopher Benson-Manica]

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

Should be "the initialization itself". And judging from your other
replies, I guess this is what you meant. The initialization to an
arbitrary string literal is probably not useful.

There are better alternatives, I'm sure, but IMHO the following is
"useful":

const char * const err_string = "Error: " __FILE__ " " __LINE__;

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Ioannis Vranos]

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:RI*****************@newsread1.news.pas.earthl ink.net...

Ioannis Vranos wrote:

Check this out:
#include <iostream>
int main()
{
using namespace std;

char array[]="12345";

*array='X';

cout<<array<<endl;
}

I'm not sure what your point is here... But I'm afraid Julie is correct.
References to pointers are fine, and your example code demonstrated a
problem because you passed an incompatible type. Try it again like this:

void func(char * const input, int word_number, char * & ptr_to_word)
{
}
int main()
{
char array[]="b";
char *p = array;
func("a",5, p); // pass a pointer, not an array
}

I think you are hinting at the usual conversion ("decay") of an array
name to a pointer. It doesn't apply when binding to a reference.

My point for the above code was that the name of an array is "converted" as
a pointer to the first element which in this case is char *. She had said:

"The function takes a reference argument of type char *, you are
(attempting) to pass a type of char[2]."
I was passing a "char *" as an address, the real problem was that the
function was accepting a char * & and there was not a char * object, so it
naturally failed.
Anyway i had expressed myself erroneusly in the beginning regarding the char
* &, and we got astray of the original subject which was about "premature
initialisation", that is initialisation with a value which is not going to
be used, but only to protect us. Such an initialisation does not protect us
in any way.


Ioannis Vranos

[Ioannis Vranos]

"Sam Holden" <sh*****@flexal.cs.usyd.edu.au> wrote in message
news:slrnc7p5eg.f7q.sh*****@flexal.cs.usyd.edu.au. ..

But this doesn't compile:

void f (char * &) { }

int main ()
{
char c;
f (&c);
}

Because the const-ness is incorrect.

"char * &" is not the same as "char * const &".

In the case of a const char * &, a temporary char * is created and the
reference points to that untill the end of the function call.


Ioannis Vranos

[Ioannis Vranos]

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:t7****************@newsread1.news.pas.earthli nk.net...

Ioannis Vranos wrote:

This uses a dangerous and deprecated language feature -- the implicit
conversion of a string literal to a (non-const) char*. I'd suggest
making your compiler warn about this if it provides such a warning.

Eh?

I'd be happy to clarify if you'll tell me which part you have a problem
with. I did already go over this in a bit more detail elsewhere in the
thread (in another reply to you, I believe), so you might check there

first.
char *s="whatever"; is not an error and i don't think any copiler exists
that ould give a warning about this. If it did, we would get thousands of
warnings in cases like this:

void whatever(char *);
/// ...

// We would get a warning
whatever("something")'
whatever( something_else() );
Even strcpy() family for example would give warnings in the case:
strcpy(destination, "something");


If you want to check the standard you can find this in D.4
[depr.string]. There's also information in 4.2/2 [conv.array]. Finally,
2.13.4 explicitly states that string literals consist of const
characters, and I know it's stated somewhere that modifying const
objects gives undefined behavior, but I'm not sure where to look.

Yes noone suggested modify string literals.
Failing to initialize in itself is not an error. But using the
uninitialized value is undefined behavior.

My point is that using an object by mistake in a way not intended to will
invoke undefined behaviour anyway. Premature initialisation does not protect
us from any of our mistakes. E.g.

#include <cstddef>
#include <iostream>
// Returns the length of the string, '\0' not included
inline std::size_t slength(char *array)
{
char *p;

// To avoid any questions, '\0'==0
for(p=array; *p; ++p)
;

return p-array;
}
int main()
{
using namespace std;

// Happily initialised
char *p=0;

cout<<endl<<slength("Pinky & the Brain")<<endl;

cout<<"\nPinky we are now protected, right?\n";

cout<<endl<<slength(p)<<endl;
}


Ioannis Vranos

[Ioannis Vranos]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...

"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...

Here is another example that is perfectly legitimate:

void func(char * const input, int word_number, char * & ptr_to_word);
// find word in input and store address in ptr

I do not think it is. You can take references from pointers only in
templates. Even in this case passing an unitialised char * would not have
any bad effect by its own.

My above response is erroneus. Noone really knows what i had in my mind. It
was after 3 a.m. ... :-)


Ioannis Vranos

[Kevin Goodsell]

Christopher Benson-Manica wrote:

Kevin Goodsell <us*********************@neverbox.com> spoke thus:

Should be "the initialization itself". And judging from your other
replies, I guess this is what you meant. The initialization to an
arbitrary string literal is probably not useful.

There are better alternatives, I'm sure, but IMHO the following is
"useful":

const char * const err_string = "Error: " __FILE__ " " __LINE__;

I meant that it's probably not useful in this particular case, which I
base on the idea that the OP apparently used it for the sole purpose of
quieting a warning. In general, string literals and pointers to them
could be useful for any number of purposes, but not as a general
catch-all char pointer initializer (such as the way 0 is sometimes used
for various types).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Ioannis Vranos wrote:

char *s="whatever"; is not an error and i don't think any copiler exists
that ould give a warning about this. If it did, we would get thousands of
warnings in cases like this:
It's not (strictly speaking) an error, but it does use a deprecated and
unsafe conversion. My compiler warns about it, because I ask it to.

void whatever(char *);
/// ...

// We would get a warning
whatever("something")'
A warning here is completely appropriate, in my opinion. You would
expect a diagnostic if you did this, wouldn't you?

const char example[] = "something";
whatever(example);

The key point here is that both calls, your example and mine, pass an
object of exactly the same type. Your example may or may not give a
warning, but in my opinion it's best if it does. My example requires a
diagnostic. Both (if allowed) are unsafe in exactly the same way. That
being that whatever() may do something like this:

void whatever(char *p)
{
*p = '\0';
}

If, on the other hand, whatever() is not intended to modify the thing
its parameter points to, it should be declared like this:

void whatever(const char *p);

Now both examples are safe and silent.


whatever( something_else() );
Even strcpy() family for example would give warnings in the case:
strcpy(destination, "something");
No, because the second parameter has type const char *.

If you want to check the standard you can find this in D.4
[depr.string]. There's also information in 4.2/2 [conv.array]. Finally,
2.13.4 explicitly states that string literals consist of const
characters, and I know it's stated somewhere that modifying const
objects gives undefined behavior, but I'm not sure where to look.
Yes noone suggested modify string literals.

But making use of the deprecated conversion from a string literal to a
(non-const) char* allows code that does exactly that, without the
compiler being able to catch and diagnose it. This (and future
compatibility) is why you should not use this conversion.

Failing to initialize in itself is not an error. But using the
uninitialized value is undefined behavior.

My point is that using an object by mistake in a way not intended to will
invoke undefined behaviour anyway. Premature initialisation does not protect
us from any of our mistakes. E.g.

I wasn't advocating an "always initialize, even if the value is not
meaningful" policy, just stating the facts as giving by the language
definition.

My personal preference is to always initialize, but do so at the point
the object is needed, not before. In other words, don't create an object
(initialized or otherwise) until you need it, then create and initialize
at the same time.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Ioannis Vranos]

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:xb******************@newsread1.news.pas.earth link.net...

void whatever(char *);
/// ...

// We would get a warning
whatever("something")'
A warning here is completely appropriate, in my opinion. You would
expect a diagnostic if you did this, wouldn't you?

const char example[] = "something";
whatever(example);

The key point here is that both calls, your example and mine, pass an
object of exactly the same type. Your example may or may not give a
warning, but in my opinion it's best if it does. My example requires a
diagnostic. Both (if allowed) are unsafe in exactly the same way. That
being that whatever() may do something like this:

void whatever(char *p)
{
*p = '\0';
}

If, on the other hand, whatever() is not intended to modify the thing
its parameter points to, it should be declared like this:

void whatever(const char *p);

Now both examples are safe and silent.

Yes you are right.
My personal preference is to always initialize, but do so at the point
the object is needed, not before. In other words, don't create an object
(initialized or otherwise) until you need it, then create and initialize
at the same time.

As i have told before these are "religious waters". For example there are
coders out there who like to put the object definitions in the beginning,
because if they want to find an object definition they wouldn't have to
search the entire code.
In any case, premature initialisation in particular (that is giving a value
not intended to be used in the program), does not protect the programmer
from any disaster.


Ioannis Vranos

[Kevin Goodsell]

Ioannis Vranos wrote:

As i have told before these are "religious waters". For example there are
coders out there who like to put the object definitions in the beginning,
because if they want to find an object definition they wouldn't have to
search the entire code.

I thought it was because they were weaned on C90. :P

Seriously, declarations should not need to be placed in a particular
location in order for them to be easy to locate. Perhaps some of these
people need to write shorter subroutines.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Kevin Goodsell wrote:

Ioannis Vranos wrote:

As i have told before these are "religious waters". For example there are
coders out there who like to put the object definitions in the beginning,
because if they want to find an object definition they wouldn't have to
search the entire code.

I thought it was because they were weaned on C90. :P

Or earlier, even. Being a fledgling myself I sometimes forget that
people were programming before 1990. ;)

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Ioannis Vranos]

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:hd*****************@newsread2.news.pas.earthl ink.net...

Ioannis Vranos wrote:

As i have told before these are "religious waters". For example there are coders out there who like to put the object definitions in the beginning, because if they want to find an object definition they wouldn't have to
search the entire code.

I thought it was because they were weaned on C90. :P

Seriously, declarations should not need to be placed in a particular
location in order for them to be easy to locate. Perhaps some of these
people need to write shorter subroutines.

Seriously i agree with you. Objects should be created only at the time we
first need them.


Ioannis Vranos

[Ioannis Vranos]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message
news:c5***********@ulysses.noc.ntua.gr...

"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:hd*****************@newsread2.news.pas.earthl ink.net...

Ioannis Vranos wrote:

As i have told before these are "religious waters". For example there are coders out there who like to put the object definitions in the beginning, because if they want to find an object definition they wouldn't have to search the entire code.

I thought it was because they were weaned on C90. :P

Seriously, declarations should not need to be placed in a particular
location in order for them to be easy to locate. Perhaps some of these
people need to write shorter subroutines.

Seriously i agree with you. Objects should be created only at the time we
first need them.

Well i guess those who talk about "premature initialisation" are a subset of
that kind of people (who like to define everything in the beginning of the
scope).


Ioannis Vranos

[marbac]

Peter schrieb:

Hi,

So many times, I have seen compile warning: "you used a char* without
initilize it", probably on the code like this:

------------
char* ptr;

func(..., ptr);
----------
char *ptr is a flying pointer which points to nowhere.
If the compiler does not fetch it, it will lead to a runtime error.

How to properly initialize a char*? I used to use

char* ptr = "";

but was told this is not good.
This is a char-pointer to an empty array of chars (/0) , when i don't
know if a char-pointer will be redirected to a char [] then i also would
do it this way. But i recommend to use string.h for string-operations.

Can anybody explain to me why, and what's a good way to initilize it?

I only can tell you what i usually do with pointers, if i am not sure:

type *ptr=NULL; // flying pointer assigned to NULL-pointer

then i can check if the pointer points to NULL (NULL-pointer ... not
assigned to valid data yet)

if (ptr!=NULL) do_something (ptr);
else cerr_something_and_exit ();

But this should not be the standard method for pointers

[Michiel Salters]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote in message news:<c5**********@chessie.cirr.com>...

There are better alternatives, I'm sure, but IMHO the following is
"useful":

const char * const err_string = "Error: " __FILE__ " " __LINE__;

Eh? __LINE__ expands to an integer, IIRC so you get something like
"Error: ""foo.cpp"" "42; which is illegal. Besides, the __LINE__
is taken from the definition of err_string, not where it's used,
which won't tell you much.

Regards,
Michiel Salters

[Michiel Salters]

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message news:<c5***********@ulysses.noc.ntua.gr>...

To make long things short, initialization doesn't protect you from anything.
The only thing that it could "protect you" in theory is in the call of
delete/delete[] family to an ititialised-to-0 pointer. In reality however
such a call occurs at the end of a process and you will have done more
things previously by mistake on that 0 initialised pointer (e.g.
dereferencing it) that would be equally disastrous/undefined.

Initialisation does not protect you from any mistake.

A well-known idiom for pointer use is :
if ( pFoo ) pFoo->doIt();

which relies heavily on default initialization to 0. The point of
the idiom is that there is a sensible default, don't call doIt(),
which is used when pFoo is the null pointer. You can't test
if (pFoo is initialised ) pFoo->doIt; // syntax error.

Regards,
Michiel Salters

[Ioannis Vranos]

"Michiel Salters" <Mi*************@logicacmg.com> wrote in message
news:fc**************************@posting.google.c om...

"Ioannis Vranos" <iv*@guesswh.at.emails.ru> wrote in message news:<c5***********@ulysses.noc.ntua.gr>...

To make long things short, initialization doesn't protect you from anything. The only thing that it could "protect you" in theory is in the call of
delete/delete[] family to an ititialised-to-0 pointer. In reality however such a call occurs at the end of a process and you will have done more
things previously by mistake on that 0 initialised pointer (e.g.
dereferencing it) that would be equally disastrous/undefined.

Initialisation does not protect you from any mistake.

A well-known idiom for pointer use is :
if ( pFoo ) pFoo->doIt();

which relies heavily on default initialization to 0. The point of
the idiom is that there is a sensible default, don't call doIt(),
which is used when pFoo is the null pointer. You can't test
if (pFoo is initialised ) pFoo->doIt; // syntax error.

We can't tell that this is "premature initialisation" and that
initialisation does not protect you from any mistakes, that is
initialisation with a value which is actively used.


Ioannis Vranos

[Christopher Benson-Manica]

Michiel Salters <Mi*************@logicacmg.com> spoke thus:

Eh? __LINE__ expands to an integer, IIRC so you get something like
"Error: ""foo.cpp"" "42; which is illegal. Besides, the __LINE__
is taken from the definition of err_string, not where it's used,
which won't tell you much.

I disagree with your assessment - the errors you listed were worthy of
at least three question marks, i.e. "Eh?????". Well, yikes. Thanks...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.