Mail Archives: djgpp-workers/2000/06/13/12:41:08
Eli Zaretskii wrote:
> On Mon, 12 Jun 2000, DJ Delorie wrote:
> > Note that I still think it's bogus that we have to bend to gcc's will,
> > instead of them accepting posix-compatible headers. But, I see no
> > harm in the patch either, unless someday some *other* header uses
> > those also to disable djgpp's specific declarations.
>
> I agree (on both counts), but something bothers me with this change.
> 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.
> 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.
> If
> not, we are shooting ourselves in the foot, because GCC might crash or
> work incorrectly in some marginal cases, due to mismatch between its
> definition of these types and the definitions we use to compile
> libc.a.
OK, if GCC definition fully hides our one, this should be treated like
a backwards not compatible change in library. 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.
Possible solutions:
1) Do Nothing. Reject my patch and possibly refrain from making GCC build
out of box. Everything will continue to work, just we will have to maintain
our little GCC fork.
2) Draw binary compatibility border line between GCC 2.95 and GCC 2.96 (3.0?)
This means applying my patch and relying on GCC to provide those types.
Everything should be recompiled with GCC 2.96, djdev version doesn't matter.
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. Everything should be recompiled with 2.04, GCC version doesn't matter.
None of solutions sounds very good to me. 1) is probably least risky.
2) and 3) sound better as a long-term solutions. 2) could be more confusing
to the users, because GCC's ABI is know to be stable. And _if_ you're
going to accept symlinks for 2.04, this would break backwards compatibility
with 2.03 as well, so there would be nothing wrong with 3) then.
(I repeat, _if_ you're going to accept...).
So I prefer the 3), but have almost nothing against 1).
> 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.
> So perhaps it is a good idea to put some safeguards into
> at least some of the affected headers that will yell bloody murder if
> some day the definitions change in an incompatible way. (Assuming
> that the preprocessor is powerful enough to support such safeguards,
> that is.)
Yes, it's a good idea, but I don't imagine how to do it with preprocessor.
Laurynas
- Raw text -