Mail Archives: djgpp-workers/2000/05/15/02:07:54
On Sat, 13 May 2000, Mark E. wrote:
> And to cap it off, here's this nugget from http://gcc.gnu.org/ml/gcc/1999-
> 09n/msg00596.html :
> >
> > When doing varargs/stdargs we absolutely do not want to be using system
> > definitions. Even if the system compiler is gcc.
>
> You can read in amazement the whole thread at http://gcc.gnu.org/ml/gcc/1999-
> 09n/threads.html#00907
Amazement, indeed. "Our way is the only way, and the rest are
dumb and braindamaged, period. No ifs, buts or howevers." Sheesh...
I'll try to keep my emotions in check and discuss the technical
aspects alone ;-).
I think this boils down to enumerating our options and choosing the
best one (or the best combination thereof). The issue is how to make
our headers be compatible with GCC's at the minimum cost, and
hopefully without breaking back-compatibility (with older versions of
GCC and/or the library).
One possibility is to put some DJGPP-friendly #ifdef's into GCC's
headers. They already have lots of system-dependent stuff for many
systems; why should DJGPP be an exception?
Since these headers are now exempt from GPL, it looks like this won't
contradict the DJGPP license. DJ, am I right (IANL)?
Another possibility is to modify our headers slightly so that they
will be compatible with GCC's. Hopefully, this will not require any
changes in the library proper; but if it will, we will need to do that
as well.
My greatest fears are with limits.h and float.h. We have there some
library-private defines, like NAME_MAX, __dj_double_epsilon, the
_control87 bits, etc. We cannot possibly hope that the version which
comes with GCC will DTRT, unless they have some trick to include the
system header from theirs (do they?). So, unless they withdraw these
two headers, we will have to change ours if they are incompatible.
Comments are welcome, as are volunteers to compare the files with ours
and post the differences here.
- Raw text -