From: Mike Stump Date: Thu, 20 Jul 2000 14:44:39 -0700 (PDT) Message-Id: <200007202144.OAA02024@kankakee.wrs.com> To: eliz AT is DOT elta DOT co DOT il Subject: Re: GCC headers and DJGPP port Cc: djgpp-workers AT delorie DOT com, gcc AT gcc DOT gnu DOT org, martin AT loewis DOT home DOT cs DOT tu-berlin DOT de Reply-To: djgpp-workers AT delorie DOT com > Date: Thu, 20 Jul 2000 02:41:28 -0400 (EDT) > From: Eli Zaretskii > To: mrs AT windriver DOT com > > From: Mike Stump > > 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 > To: mrs AT windriver DOT com > > From: Mike Stump > > 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 > 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 > 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 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.