Message-ID: <39478705.3C3BE6A0@softhome.net> Date: Wed, 14 Jun 2000 16:22:13 +0300 From: Laurynas Biveinis X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: lt,en MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: Patch: sentinels for typedefs in headers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > > 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. If type definitions are identical, both cases don't differ much for our discussion. > 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. Right. > > > 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? Catched another one - our wint_t is 'int' and their 'unsigned int'. > > 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. Yes. > > > 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? So far I have found only this (and now wint_t) issue. > 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. We convinced them not to install float.h due to the same arguments. > 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... But I still haven't seen this kind of breakage. C ABI seems to be stable to me for a few last major releases. Laurynas