Noel L Yap wrote:
>
> I've noticed that xmalloc does not zero out the memory that's just been
> allocated.
Right. It shouldn't have to. Well-written programs do not access
uninitialized memory.
This doesn't jive well when adding new fields to existing structures
> (specially these structures don't have a common constructor-type function to
> initialize the memory).
If they are complicated enough to need some sort of constructor
function,
then that's what they should have. This may make it more difficult to
make certain changes to the code, but it seems to me that making such
changes is going to make the code harder to maintain in the future.
Further, it adds to the unwritten assumptions that the code depends on.
I realize that there are a good many hacks in all the software that
we're using here, but I see no reason to encourage these hacks.
What winds up happening is that these fields contain
> garbage. This is fine when these fields aren't used, but when these fields are
> pointers, they are always used by the function that frees the memory causing a
> core dump.
>
Yes. This tends to happen with code that mismatches mallocs and frees.
I consider this at least partly a useful feature, in that it points out
that there is a problem with the code, and the dump will show what's
failing.
> For safety, I propose that xmalloc zero out the memory it allocates. Any
> comments or rebuttals?
>
For safety, I would prefer it does not. I don't think we should
use non-portable solutions to cover up the faults of badly-written
software. I'd feel more comfortable using the software knowing that
some classes of errors would have been discovered.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
