[EMAIL PROTECTED] on 05/02/2000 06:58:16 PM
>> > 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.
>
>So you would rather have problems occur *randomly* depending on what the
>values *happen* to be at the moment? Personally, if something is not
>properly initialized I'd like a core dump every time so that it is found
>and fixed quickly.
I think the question boils down to what are the priorities CVS is aiming for.
Either reliability takes a back seat to performance or vice versa. It's true
that it's possible to have both, but we've all seen that this doesn't happen in
practice without a lot of effort (eg running memory checkers, ...). Since CVS
progresses due to the time given by volunteers, we can't presume that the goals
of reliability and performance can be met perfectly all the time. "Portability"
(in the sense that the software acts the same on all platforms) is also a goal.
The original problem I ran into occurred because the free function for the
structure free'd uninitialized fields (that were _never_ used (other than the
free) in the part of the code that allocated and used the structure).
If xmalloc() zeroed out memory, free's of uninitialized (and unused) fields
would get fixed for all the platforms that define NULL as zero -- I don't know
of any platforms that don't. This would come at a cost of slowing down
xmalloc() a bit -- I don't know how much, but I doubt it would increase it's
order of complexity.
Creating a constructor for this structure would also fix the problem. This
solution seems more preferable since it would tend to meet both goals quite well
(although it would add an extra function call). Note that such a constructor
could, in fact, slow the code down more than expected due to possible deep
copies of pointers.
Noel
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction, unless specifically agreed
otherwise. All market prices, data and other information are not warranted as
to completeness or accuracy and is subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.
