is this valid ?

[grahamo]

somefunc(char** arg)
{

*arg =strdup("hello world");
}

someotherfunc(char** arg)
{

char* tmp = strdup("goodbye world");
arg = &tmp;
}


int main(int argc, char** argv)
{
char** foo;
char** bar;

somefunc(foo);
someotherfunc(bar);

return 1;
}


On some platforms I've tested these work, on some others the don't.
Are the uses of somefunc and someotherfunc above valid?


How can I dereference arg in somefunc above when it hasn't been
initialised to anything? Or is it plain old rubbish?


thanks


Graham

 

[Andre Kostur]

(e-mail address removed) (grahamo) wrote in

somefunc(char** arg)
{

*arg =strdup("hello world");
}

someotherfunc(char** arg)
{

char* tmp = strdup("goodbye world");
arg = &tmp;
}


int main(int argc, char** argv)
{
char** foo;
char** bar;

somefunc(foo);
someotherfunc(bar);

return 1;
}


On some platforms I've tested these work, on some others the don't.
Are the uses of somefunc and someotherfunc above valid?

No. First problem, both of those functions have no return type. All
functions must have a return type (except constructors and destructors,
if you consider those functions).

How can I dereference arg in somefunc above when it hasn't been
initialised to anything? Or is it plain old rubbish?

Second problem. foo doesn't point anywhere useful at the time it's
passed into somefunc. And since somefunc deferences foo (techinally
arg), which is uninitialized, you've invoked undefined behaviour. Your
program can do whatever it wants. Fix: declare foo as a char*, and pass
&foo to somefunc.

Third problem. someotherfunc effectively returns a pointer to a local
variable (in this case, a pointer to a pointer). Right after
someotherfunc returns the contents of where tmp used to be may be garbage
data, which you're attempting to pass back in bar.

Fourth problem. someotherfunc assigns &tmp to arg. Unfortunately arg is
passed by value, so that gets thrown away right after the function
returns.

Fifth problem. I see two calls to strdup, but no calls to free. Memory
leak.

 

[David Harmon]

On 14 Apr 2004 14:23:25 -0700 in comp.lang.c++,
(e-mail address removed) (grahamo) wrote,

How can I dereference arg in somefunc above when it hasn't been
initialised to anything? Or is it plain old rubbish?

Plain old rubbish. Or in the words of the standard, "undefined
behavior." Which means, if at all possible, it will appear to "work"
whilst testing and then plainly "not work" whilst demonstrating for your
boss or customer.

 

[Kevin Goodsell]

Second problem. foo doesn't point anywhere useful at the time it's
passed into somefunc. And since somefunc deferences foo (techinally
arg), which is uninitialized, you've invoked undefined behaviour.

Undefined behavior is invoked just by passing the uninitialized values.

Fifth problem. I see two calls to strdup, but no calls to free. Memory
leak.

I don't see a definition for strdup(), so I don't know what it returns,
or what responsibilities the caller may have.

-Kevin

 

[Andre Kostur]

Undefined behavior is invoked just by passing the uninitialized
values.
True..


I don't see a definition for strdup(), so I don't know what it
returns, or what responsibilities the caller may have.

OK, I'm assuming the most well-known strdup (my bad).... wasn't sure
whether it's defined in the Standard....

 

[Kevin Goodsell]

OK, I'm assuming the most well-known strdup (my bad).... wasn't sure
whether it's defined in the Standard....

For future reference, it's not part of the C90 or C++ standards. As far
as I can recall, it was also not added to C99. I believe it is a POSIX
function.

-Kevin

 

[grahamo]

Awesome, awesome, awesome. Thanks for both those responses, I'm all
set now. I actually expected the answers you gave its, simply that
some compilers let you get away with some of this stuff and some
don't.


On the subject of which, where does one get ones hands on a copy of
the ansi c++ spec.... without paying for it?

cheers


GrahamO

 

[Bill Seurer]

... simply that
some compilers let you get away with some of this stuff and some
don't.

The compiler wasn't letting you "get away" with anything. The reason it
works sometimes is shear luck based on whatever memory location the
uninitialized pointer happens to be pointing to.

 

[Kevin Goodsell]

Awesome, awesome, awesome.

Please don't top-post. Check section 5 of the FAQ for posting guidelines.

Thanks for both those responses, I'm all
set now. I actually expected the answers you gave its, simply that
some compilers let you get away with some of this stuff and some
don't.

This is the wrong conclusion. In undefined behavior territory, anything
goes. It could work today and not tomorrow. It could do something
completely unexpected. There are no requirements, not even for
consistent or reasonable behavior.

On the subject of which, where does one get ones hands on a copy of
the ansi c++ spec.... without paying for it?

The C++ Standard is provided by the various national standards bodies
(such as ANSI in the U.S.). As far as I know, none provide it for free.
ANSI sells an electronic copy online for US$18 last I heard.

There are drafts that were made publicly available. You can find some on
the committee's web page, here:

http://std.dkuug.dk/jtc1/sc22/wg21/docs/wp/

The latest draft on that page is fairly close to the final standard, but
don't expect it to be completely accurate. There are also various defect
reports. If something doesn't make sense, or if you want to check the
accuracy of it, looking for defect reports can help. The DRs are also on
the committee's page somewhere.

-Kevin