[Libav-user] g++ 4.7.2 fails to compile av_err2str

[Nicolas George]

Le quintidi 25 nivôse, an CCXXI, "René J.V. Bertin" a écrit :
> Are you sure? I was under the impression that
> 
> n = 10;
> { char *foo = (char*) alloca(n); // char foo[n] in gcc :)
> 	// fill foo
> 	printf( "%s\n", foo );
> }
> 
> is equivalent to
> 
> { char foo[10];
> 	// fill foo
> 	printf( "%s\n", foo );
> }
> 
> meaning that the stack-deallocation of *foo happens upon exit from the
> block, like the releasing of foo[10] ...

I checked both in the man page (from gcc+glibc) and a test program: if you
use alloca() inside a loop, it returns a new block each time, while a
compound literal has always the same address. The man page says:

# This temporary space is automatically freed when the function that called
# alloca() returns to its caller.

> In my book, a memory leak is memory that's allocated but never
> deallocated. That's not the case here... it's more like a
> caching/garbage-collection scheme.

Except that there is no garbage collection when the memory runs out. I count
a block of memory that is freed later than expected without way of catching
it as a leak. Otherwise, there would be no leaks possible, all memory is
freed when a process terminates.

> And as long as there are few errors being reported, there won't be much
> memory to free.

The stack can be quite small, and errors can be numerous. You can get errors
to report very frequently. I see some OSes have a default thread stack of
64k, that is 1k errors. Decoding damaged streams from network can produce
that kind of output.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130114/2cbf6d15/attachment.asc>