Mail Archives: djgpp/2000/08/22/02:27:44
> From: Jason Green <news AT jgreen4 DOT fsnet DOT co DOT uk>
> Newsgroups: comp.os.msdos.djgpp
> Date: Tue, 22 Aug 2000 00:32:28 +0100
> >
> > If you would like to work on this, please do. Thanks.
>
> Certainly, I can produce a patch to replace the malloc() calls if it
> is agreed that this would be worthwhile.
It certainly cannot hurt, so please go ahead if you feel like it.
> My observations, however, are that the code makes many assumptions
> about the successful return of system calls, mostly malloc(), fread()
> and fseek(), and that these should be tied down.
It could be useful, yes, provided that the error messages say
something a user can grasp.
> 1) replace malloc with either xmalloc or calloc (I am still not
> convinced about this BTW).
I vote for xmalloc.
> > > 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:
>
> That is not bourne out by the comments from Charles Sandmann, AIUI.
I think it is. What Charles said, plain and simple, is that he didn't
zero out storage unless he saw some bug. But the decision not to zero
it out by default was due to performance considerations.
> > 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.
>
> There is a performance hit, but would it be noticeable in this case?
Yes, definitely. Especially on a memory-starved machine, where the
calloc code will case SYMIFY to page.
> > 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.
>
> Except that the file reads are not checked to see if the entire buffer
> was filled. Zeroing the buffers would at least allow some consistency
> in future crashes so that bugs could be caught.
Sorry, I disagree. First, zeroing out will bring a performance hit to
*all* SYMIFY invocations, not only to those where the binary is
damaged.
And second, the read operation can only fail if the debug info or the
COFF headers are incorrect, in which case it really isn't important
whether SYMIFY will crash immediately or later.
- Raw text -