Mail Archives: djgpp-workers/2000/07/22/18:36:41
> Date: Sat, 22 Jul 2000 10:32:55 -0600
> From: Jeffrey A Law <law AT cygnus DOT com>
>
> In message <200007220919 DOT FAA12001 AT indy DOT delorie DOT com>you write:
> > My information indicates that the relevant headers are: assert.h,
> > stddef.h, iso646.h, limits.h, stdbool.h, and syslimits.h.
> I would be willing to consider not installing if and only if we
> know the system versions are correct. Just saying yours are correct isn't
> sufficient, you actually have to test them.
You mean, tested by the configure script? Please tell what features
need to be tested, and we will try to submit the necessary changes to
the configury.
> I think you'll find that it's far easier to just let GCC install the
> headers it expects and deal with it.
We already discussed that possibility at length on the DJGPP
developer's list, and arrived at a conclusion that it is much easier
for us to use our headers.
> Other systems which have their own stddef.h, limits.h, etc etc manage to
> work just fine when using GCC's versions. Why can't yours?
The main reason is that DJGPP releases are infrequent and the
development team is small. We cannot afford to track the high rate of
changes characteristic to the GCC development. If some change in
GCC's headers breaks something in DJGPP library, that breakage is with
us for quite a while, generating lots of FAQs on the DJGPP news group.
There are other reasons as well; I think they were mentioned in this
thread.
> Let's take the __null issue again.
I think this is now solved. We will change our headers to define NULL
as 0 for C programs only, and let C++ programs use the definition
provided by the headers which come with libstdc++.
> Now, let's assume that you fix your stddef.h and claim that you're compliant
> now. You may be right as far as NULL is concerned, however we may come across
> other compliance issues in the future which might require additional tweaks
> to stddef.h, stdbool.h, etc.
This might indeed happen, but this is a different problem: it means
that new features provided by new releases of GCC won't be fully
supported by DJGPP until an updated libc is released. Since these new
features were not available previously, this is less painful than
having a new GCC release break old code. So we are more willing to
take the risk of losing some of the new features than the risk of
breaking old ones.
- Raw text -