[ Moved to tech-toolchain ]

Erik Bertelsen <erik@mediator.uni-c.dk> writes:

> On Wed, Dec 22, 1999 at 01:26:21PM -0800, Klaus Klein wrote:
> >
> > Added Files:
> > 	basesrc/include: null.h
> > 
> > Log Message:
> > For the benefit of G++'s null pointer constant implementation, #define NULL
> > as __null with egcs 1.0 (GCC 2.90) and above.  As several headers are affected
> > by this change, move the definition into a new header file, <null.h>, to ease


> May I request a big explicit comment in <null.h> that no-one except
> the system headers themselves should ever include <null.h> as this
> is not portable.  The ISO C standard specifies that NULL is defined
> in several of the headers that now include <null.h>, and everyone
> should still include one of these to define NULL.

Yes, that is indeed a problem.  I'd prefer a more drastical method
though, such as <null.h> testing for one of the including headers'
idempotency macros being defined and raising an #error if not.

That partially defeats the original aim of maintenance ease, however.
Combined with your other point:

> Also do we break strict adherence to ISO C by having <stddef.h>
> etc. actually include other headers? I have faint recalls about the
> standard saying that inclusion of these headers don't cause other
> headers to be included ...  (which is possibly the reason that NULL
> is defined in several places).

A quick search of C89 and the latest C99 draft document I have access
to (N869) didn't yield anything assorted (though I might easily have
missed it), but given the (possible) problem you point out above I'm
considering either moving the full definitions of NULL back into each
header file, or using the GCC-like approach of making NULL a special
case in <stddef.h> and including that header (with an additional
feature request symbol defined) from those that need NULL.


Comments?