Mail Archives: djgpp-workers/2000/06/14/12:10:22
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 <stdarg.h> 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
- Raw text -