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
signature.asc
Description: Digital signature
_______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
