Mail Archives: djgpp/1995/10/06/16:01:26
> Isn't calloc() the function you're supposed to use if you want
> zeroed memory anyway?
Sure, if you want bug free code :-)
The problems happen when programs access uninitialized memory (variables
on the stack, or non-initialized malloc()ed memory. The program may work
under V1.x since that memory is always zeroed. Under V2.x the memory
contains what happens to be there from a previous program, so the
behavior may change (or SIGSEGV) when these sorts of bugs happen. So, if
you run a V2 program twice and get 2 different behaviors, it's a uninitialized
memory bug. Note, the malloc memory is only zero the first time it is used
(fresh from sbrk) and not if freed and re-used.
So, there are two optional flags in V2 for memory handling. One indicates
that memory should be filled with zeros (good for backward compatibility
when you don't want to find the time to fix the bugs). The other fills
the memory with the value 0xdeadbeef, which is easy to spot in registers
and memory when debugging (to find those nasty bugs; pointers which end
up with value will puke). The down side is that filling memory degrades
performance a bit if you have enough memory and a LOT if you start paging.
There was some code in the V1.x libc (such as malloc) which depended on
sbrk()ed memory being zero to work. We have fixed those in V2, but we
can't fix all the other programs out there...
Items like this belong in a V2 porting guide which hasn't been written yet.
Oh, BTW, make sure those file name buffers are at least 260 chars for V2,
or you'll need to set another flag to disable long file name support too...
- Raw text -