[Lame-dev] Re: [Lame-cvs] lame/libmp3lame VbrTag.c,1.32,1.33 util.c,1.84,1.85

[Mark T. <mt...@mp...>]

> On 17 Sep, Mark Taylor wrote:
> 
> > Modified Files:
> > 	VbrTag.c util.c 
> > Log Message:
> > moved a 1M array from stack to heap in VbrTag.c
> > 
> > Some OS, when launching LAME on a seperate thread,
> > allocate a tine (128K?) stack.  moving this to the heap
> > is an ugly solution (requires a malloc() and free())
> > but lets see if it fixes the reported segfaults.
> 
> Without looking at the patch:
> - You hopefully replaced it with calloc instead of malloc, and also
>   removed the memset(buffer, 0, sizeof(buffer))?
> - Why is this an ugly solution?
> 

No, I forget about calloc() :-).  But the whole section of code will
eventually be called from copy_buffer() and comupte the music crc
on the fly.  I really dont like having file I/O in the library.  

As for malloc/free vs. automatic arrays: If the size is known at
compile time, I dont like using malloc() and free() because they are
error prone.  For example, the bug just fixed because s3_ll was
malloc() and never free'd.  s3_ll used to be a double array,
s3_l[CBAND][CBAND], which was simple and had no memory leaks.  I
didn't like it when someone switched this to s3_ll[], to either save a
few bytes or may improve speed?  The end result is that we had a
memory leak that was undetected for many months.

My ISP is being DOS'ed by that new virus, so I'm not recieving
lame-dev  - sorry if this has already been discussed.

Mark