Mail Archives: djgpp-workers/2000/06/14/05:48:31
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 <stdarg.h> 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...
- Raw text -