Mail Archives: djgpp/2000/08/20/13:00:19
> 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.
In the beginning there was GO32, and it was good. It would zero memory when
a page was first touched, on demand. So when sbrk() asked for memory, it was
zero by default. Then came Windows. Windows is a control freak and refused
to let GO32 play in the same sandbox, wanting it to DPMI instead. GO32 was
taught to DPMI, but DPMI didn't zero memory. This was faster, but most unix
code is buggy, assuming memory will be zeroed, and there was a plague on the
DPMI code because of the bugs. The GO32-DPMI was made to zero all memory,
which made it slower, but it ran the buggy code and things were good again.
DJGPP V2 was built on DPMI to begin with, and we decided to fix the "expecting
zeroed memory" bugs instead of having to have zero all memory (there is still
a crt0 option to turn this on, BTW). When trying to build edebug32 during the
V2 prototyping stage I found uninitialized memory bugs and fixed them so the
debugger would run. I didn't analyze every line of code - just found bugs
and fixed them. The note observed in the code was from one of those fixes.
When I suspect uninitialized memory bugs, I rebuild (or patch the binary image)
to set the crt0 flag to zero memory. If the bug goes away, smoking gun. We
should probably run all code with the deadbeaf flag to try and catch these
things but we never had time...
- Raw text -