Mail Archives: djgpp/2000/08/19/18:00:20
"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> wrote:
> Thanks for catching this, this is indeed a bug.
> (In the v1.x days, it worked because
> malloc returned zeroed-out storage.)
That's interesting to know.
> > Also, ISTR that generally accepted best practice is *not* to cast the
> > return from malloc() so the code should read:
> >
> > syms = malloc(num_syms * sizeof(SymNode));
>
> Yes, but that's not really a bug. Casting malloc doesn't produce
> invalid code, it just obscures possible problems from not including
> stdlib.h, which in this case *is* included.
Very true. It's more a style issue, and scanning through the code
suggests this may be the least of the problems. ;-/
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. Or replace with calloc(), since, as you
say, the code was originally written when malloc() zeroed-out memory.
I won't pretend to understand what any of the code does, but scanning
through syms.c I see another potential bug:
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;
- Raw text -