Mail Archives: djgpp/2000/08/20/02:05:21
> From: Jason Green <news AT jgreen4 DOT fsnet DOT co DOT uk>
> Newsgroups: comp.os.msdos.djgpp
> Date: Sat, 19 Aug 2000 22:58:35 +0100
>
> If the code is to be patched, do you think it would be worth doing a
> global replace on all the malloc() calls?
>
> Either change them to xmalloc(), as is done in symify.c, since returns
> are never checked for NULL.
If you would like to work on this, please do. Thanks.
> Or replace with calloc(), since, as you
> say, the code was originally written when malloc() zeroed-out memory.
No, this is actually not a good idea, and I'm sure whoever wrote that
stuff didn't use calloc for a good reason: calling calloc causes the
DPMI server to page in all the memory, in order to initialize it.
This could be a performance hit for large programs where the symbol
table is several MBytes long. It is also unnecessary, since the code
reads in the data into the malloc'ed buffers right away, and the data
*must* by definition fill the entire buffer, because the size of the
data was read from the COFF headers.
> In the function process_coff(), this code (line 188) appears to have
> been fixed to zero-out f_string_table:
>
> fread(&strsize, 1, 4, fd);
> f_string_table = (char *)malloc(strsize);
> /* CWS note: must zero or pukes below. Does not fill from file. */
> memset(f_string_table,0,strsize);
> fread(f_string_table+4, 1, strsize-4, fd);
> f_string_table[0] = 0;
>
> But in the little used process_aout(), some similar code (line 324)
> has not been fixed:
>
> fread(&string_table_length, 1, 4, fd);
> f_string_table = (char *)malloc(string_table_length);
> fread(f_string_table+4, 1, string_table_length-4, fd);
> f_string_table[0] = 0;
It looks like the call to memset in process_coff was added due to
specific bug which Charles Sandmann (that's what CWS stands for) found
while debugging the code.
I cc: Charles, perhaps he remembers what was that about.
- Raw text -