Derek Scherger wrote:
>
> > > 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.
>
Ideally, I'd rather not have problems. Since that isn't possible,
I'd like them to show up definitely and emphatically. I don't like
solutions that patch over problems in most cases, particularly since
CVS is used in a very wide range of environments to control very
important files. (My company's primary asset - aside from people -
is the software base currently managed by CVS.)
If xmalloc is to initialize memory, I'd prefer it to be initialized
to something obviously bad. Jonathan Gilligan had some very good
suggestions. Now, "obviously bad" is system-specific, but it's better
than initializing to a value selected to be innocuous. (Steve Maguire,
in "Writing Solid Code", p. 49, gives some good pointers on selecting
a bad value.)
So I'd rather have random crashes than lurking bugs, assuming the
crashes occurred sufficiently often, and I'd rather have reliable
crashes than random.
About the free(0) issue: ISO C requires free() to handle a null
pointer correctly, so any concern on this part is catering to
non-standard C libraries. It's been over ten years since C was
standardized by ANSI, and it's even gotten a new standard. If
we're going to make sure CVS runs properly on non-standard C
implementations, we should try to make sure it runs properly on
odd hardware with conforming implementations also, and that means
not relying on the value of binary zeros for pointer or floating-
point values.
--
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/
