Date: Sun, 20 Aug 2000 09:07:32 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: news AT jgreen4 DOT fsnet DOT co DOT uk
Message-Id: <7263-Sun20Aug2000090732+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b
CC: djgpp AT delorie DOT com, sandmann AT clio DOT rice DOT edu
In-reply-to: <drutpscncl1imai9btj7k697natrpbtnqr@4ax.com> (message from Jason
	Green on Sat, 19 Aug 2000 22:58:35 +0100)
Subject: Re: Symify crash
References: <3 DOT 0 DOT 5 DOT 32 DOT 20000813122244 DOT 007c0c00 AT pop DOT mail DOT yahoo DOT com> <3405-Sun13Aug2000163046+0300-eliz AT is DOT elta DOT co DOT il> <3996E3F4 DOT C9B37F8B AT softhome DOT net> <2593-Sun13Aug2000214525+0300-eliz AT is DOT elta DOT co DOT il> <fadqpscd8dj2q2la9jbojdvuou9a9283vl AT 4ax DOT com> <7704-Fri18Aug2000203741+0300-eliz AT is DOT elta DOT co DOT il> <m91rps83eoo8thnrmjumrbg1i9fhdlbf8a AT 4ax DOT com> <1438-Sat19Aug2000213809+0300-eliz AT is DOT elta DOT co DOT il> <drutpscncl1imai9btj7k697natrpbtnqr AT 4ax DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 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.