Mail Archives: djgpp/1998/06/29/01:02:14
> Actually, no.. It's a bug in the C libraries..
The ANSI specification disagrees with you. ANSI states that certain
system headers (including stdio.h and stdlib.h) *will* define a macro
called NULL, with no claims about undef'ing it first. Any program
that assumes that it can define NULL its own way and safely include
stdio.h is in violation of the ANSI specification.
> While the C-libraries are quite ignorant and simply do:
>
> #define NULL
The C libraries are following the ANSI specification. The C++
libraries are not.
> Regardless of the conflicts which could arise from doing so.
>
> > A recent discussion among DJGPP developers couldn't yield an agreement
> > about what's the best way and place of fixing this. In particular, DJ
> > Delorie objects to a change in DJGPP's C headers.
>
> Well.. Not to jump the gun or anything, but isn't that quite dumb? I
> mean, the fix is quite simple, if NULL is already define, do NOT
> redefine it. This wouldn't make the C libraries any worse, only more
> compatible.
No, it's not dumb. Is it wise to shut off radar detectors, so that
one could claim that there are less reported speeders? It is wise to
lock a hospital door, so that there are less reported accidents? Is
it wise to allow programs to dereference zero, so that there will be
less core dumps? No, none of these are wise - they hide the root of
the problem, rather than fix it. Same with NULL. DJGPP is *one*
implementation of the ANSI spec. The fact that the GNU C++ headers
are broken under DJGPP means that they are broken - and that other
platforms are hiding this brokenness, rather than complaining about
it. It would not be wise to "fix" djgpp's headers to hide the bug
in the C++ headers, because if we did the headers would not get fixed.
Besides, once we start down this road, there would be no end. What
about all the *other* symbols defined in djgpp's standard headers? do
we need to protect *everything* from broken programs?
I suppose a quick fix would hide all the broken programs out there,
but is that the best solution? Wouldn't you rather have programs that
follow the rules?
> > So for now, your best bet would be to fix your own headers the best you
> > can (I suggest doing that in the C++ header(s) that rewdefine NULL).
>
> Like I said, the C++ libraries never redefine (they check to see if
> NULL exists and if so don't attempt to redefine it).. It's the C
> libraries which are the problem.
Actually, it's the programs that include the C++ headers *before* the
C headers that are broken. However, C++ headers that themselves
include C headers after defining NULL, are also broken. The action
that makes them broken is that they define NULL and then include a
standard header. Whoever causes this action is broken.
- Raw text -