Re: Returning automatic pointers always bad?



pete <pfiland@xxxxxxxxxxxxxx> writes:

Richard wrote:
pete <pfiland@xxxxxxxxxxxxxx> writes:

C. J. Clegg wrote:
Consider the following:

char *foo( void )
{
char *bar = (char *)NULL;

bar = malloc( 40 );

return bar;
}

int main( void )
{
char *foobar = (char *)NULL;

foobar = foo();

doSomethingWith( foobar );

free( foobar ); // safe even if foobar is NULL
foobar = (char *)NULL;

return 0;
}

Now, foo( ) is returning an automatic pointer, which as we all know
goes out of scope as soon as foo( ) returns. In this case, that
should be OK, right?... because that pointer is assigned to another
pointer (foobar in main()) which continues to point to valid heap
memory even if bar goes out of scope.
The code is OK but your reasoning is wrong.
foo returns the same value returned by malloc.
It makes no difference whether or not an automatic variable
once held this value before foo returns.

His reasoning was correct enough if you dig into what he said : "the
pointer is assigned to another pointer which then continues to point to
valid memory". Implicit is "pointer value" when mentioning assigning a
"pointer" in this kind of chat.

No.
OP is expressing concerns about the value of (bar) being returned
because (bar) has automatic storage.
The assignment to (foobar)
has nothing to do with (bar) being an automatic variable.

OP is mixed up about the difference between
returning the value of an automatic pointer,
which is an unremarkable thing for a function to do
and
returning a pointer to an automatic vaiable,
which is a wrong thing for a function to do.

Yet at no point was a pointer TO an automatic variable mentioned.

You could be right. I personally did not read it that way. But then I
tend to see around corners at times too :-;

And the reason I think this is clear: Its where he says the following:

,----
| >>>> assigned to another
| >>>> pointer (foobar in main()) which continues to point to valid heap
| >>>> memory even if bar goes out of scope.
`----

The "continues to point to" is the pivot for me.

But yes, I take your point as to how you read and can well accept it.



If foobar were indeterminate, then there would be a problem with
doSomethingWith( foobar );

char *foo2(void){return malloc(40);}
There's no difference between what your foo does and what foo2 does.
There's no difference between the way that your foo can be used
and the way that foo2 can be used.
.



Relevant Pages

  • Re: Insert with response
    ... FooBar, there's no way and no need to put them in synch. ... column in the foo table to 250 calumns in the bar table. ... set statistics time off ...
    (microsoft.public.sqlserver.programming)
  • Re: Factory or Inheritance for Initialisation?
    ... Originally the inheritance tree used template method to define the ... As far as FooBar is concerned, Foo and Bar have the same ...
    (comp.object)
  • Re: whats a callback?
    ... Rene may have ... 'foo' needs to be written now, which has to call another function ... 'bar' that may not exist yet. ... So you declare the interface signature of 'bar', and make a pointer to ...
    (comp.arch.embedded)
  • Re: whats a callback?
    ... Rene may have ... 'foo' needs to be written now, which has to call another function ... 'bar' that may not exist yet. ... So you declare the interface signature of 'bar', and make a pointer to ...
    (sci.electronics.design)
  • Re: "Mastering C Pointers"....
    ... > Windows shortcut, there is definitely an analogy there. ... a pointer variable holds an address of an object. ... int foo = 12; ... int *bar; ...
    (comp.lang.c)