Mail Archives: djgpp-workers/2000/07/20/17:45:09
> Date: Thu, 20 Jul 2000 02:41:28 -0400 (EDT)
> From: Eli Zaretskii <eliz AT delorie DOT com>
> To: mrs AT windriver DOT com
> > From: Mike Stump <mrs AT windriver DOT com>
> > Date: Wed, 19 Jul 2000 14:35:28 -0700 (PDT)
>
> If you mean that we should submit patches to the GCC maintainers to
> fix the headers installed by GCC, then that's a maintenance burden
> we would like to avoid, at least for the headers that there's no
> real need for GCC to install.
I have given you three options in my other message, let me know which
path you wish to take, and I will be able to help you with the above.
> Date: Thu, 20 Jul 2000 02:44:16 -0400 (EDT)
> From: Eli Zaretskii <eliz AT delorie DOT com>
> To: mrs AT windriver DOT com
> > From: Mike Stump <mrs AT windriver DOT com>
> > Date: Wed, 19 Jul 2000 14:44:15 -0700 (PDT)
> >
> > > Could you tell what other headers do we need to consider?
> >
> > I'd rather tell you how to find the compiler include directories
> > (touch t.c && gcc -v t.c), and how to run ls (dir).
> The question was about future GCC releases, for which I cannot
> simply look in my include directories.
Don't worry about that future. It will come and you can't stop it.
Good, bad or indifferent. What we can worry about it what is most
likely to be in the next release. This can be answered by looking in
the compiler's include directory, just as I said.
> > errno.h limits.h proto.h varargs.h assert.h exception math.h
> > stdarg.h syslimits.h curses.h fixed new stdbool.h typeinfo
> > cxxabi.h iso646.h new.h stddef.h
> Are all of these relevant for C programs?
No.
> Ideally, I'd like to get rid of all of the above-mentioned headers
> except varargs.h and stdarg.h. What would we (the DJGPP
> maintainers) need to do to come as close as possible to that goal?
Submit patches, and be right and be willing to back it.
> Date: Thu, 20 Jul 2000 06:24:10 -0400 (EDT)
> From: Eli Zaretskii <eliz AT delorie DOT com>
> To: martin AT loewis DOT home DOT cs DOT tu-berlin DOT de
> What is of interest to us is what will a C function see when called
> with a __null argument from a C++ program. This is required to DTRT
> in C headers so that they would work with C++ programs regardless of
> the order of headers inclusion (since some headers in libstdc++
> define NULL).
Do you actually expect the compiler is so broken such that the answer
would be anything other than NULL? It is not so broken, nor has it
ever been. You could have easily asked the compiler this as well, if
you cared.
> Date: Thu, 20 Jul 2000 10:37:16 -0400
> From: DJ Delorie <dj AT delorie DOT com>
> To: djgpp-workers AT delorie DOT com
> > I don't know what your copy of stdio.h looks like, however, it
> > should certainly test whether NULL is defined before defining it.
> It doesn't. It shouldn't have to. ANSI says that stdio.h provides
> NULL.
Gosh, my copy of a C standard says:
53. The macro NULL is defined in <stddef.h> as a null
pointer constant; see 7.1.6.
Can you explain this? Do other C langauge standards not have this?
Which ones?
> I have a philosophical problem with anyone saying "it should
> certainly test it" because it means that, at the whim of the gcc
> team, we'd need to add yet another test to our standard headers
> because yet another symbol was absconded by the gcc headers.
Or, maybe it is for another reason, like a hard requirement of some
language standard?
> Where does it end? Do we have to wrap every single #define in all
> the system headers? Will we have to wrap the function prototypes
> also?
The sky is falling... Don't worry, it is not. Trust us.
If you find a bit of misplaced sky, just tell us, submit a patch to
fix it, and the world continues on.
- Raw text -