Date: Wed, 14 Jun 2000 12:18:53 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: djgpp-workers AT delorie DOT com Subject: Re: Patch: sentinels for typedefs in headers In-Reply-To: <39464F5E.7991316@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 13 Jun 2000, Laurynas Biveinis wrote: > > Effectively, it means that we use one definition of size_t and its ilk > > when building GCC and another when building other programs and libc.a. > > No - if GCC installs its own header, it will hide our one completely. First, I wasn't aware that GCC binaries will now be distributed with GCC's versions of those headers. I thought we were only discussing how to make GCC *compile* out of the box. We might still want to refrain from *installing* the headers, after the compilation. In general, I don't see how it could be a good idea to install GCC headers, unless (1) each one of them has an #include_next, and (2) the overlapping parts are identical. If GCC's headers do not include ours, there's no way we could make sure that non-standard parts that we put into our headers are there when some application needs them. > > Are we absolutely sure that these definitions are *identical*? > > va_list isn't. GCC typedefs va_list as __builtin_va_list, and va_start > etc. macros expand to builtins too. Personally I prefer them and IMHO > even making our own stdarg.h / varargs.h to use them is a good idea. DJ, do we have any reason not to use GCC's definition of va_list? However, va_list is just one definition. What about all the *_t typedefs, and other things that are part of these headers? > User's program doesn't care, > did GCC or DJGPP change va_list. It just cares that it should be recompiled, > because it is not binary compatible with new code then. It also means that libraries compiled with previous headers are not compatible anymore, if they use one of those features. > 3) Draw that line between DJGPP 2.03 and 2.04. > This means applying my patch and converting to use builtins > for 2.04. This assumes that stdarg.h is the only locus of possible problems. Is this assumption correct? There's a fundamental issue here: the language standard permits system headers to include extensions and non-standard features supported by the library. If we use GCC's headers instead, it is not at all trivial, perhaps even impossible, to make sure those extensions will work correctly, because GCC maintainers don't know anything about them, and don't care. > > Even if today these definitions are identical, they might diverge in > > the future. > > IMHO it's not very possible. Unless the change is cosmetical, it would > break *all* the GCC platforms. This sounds to me more like GCC maintainers > commiting a suicide. I don't see any evidence to the fact that GCC maintainers are cautious not to break other platforms. I see lots of evidence to the contrary, unfortunately. I guess that's the ``virtue'' of the bazaar-style development...