>--- Forwarded mail from [EMAIL PROTECTED]
>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.
Whenever I implement a new data structure, the first routines I write
are create/initialize and destroy routines. The first allocates whatever
memory is needed, and initializes the structure completely and explicitly.
The last one deallocates all memory associated with it. If I add a new
field, I modify these routines accordingly. Usually it takes only a few
minutes, and the code is always portable (which is not the case when
a block is filled with zero bits).
>--- End of forwarded message from [EMAIL PROTECTED]