Re: GCC headers and DJGPP port

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Thu, 20 Jul 2000 18:30:42 -0400
> From: DJ Delorie <dj@delorie.com>
> To: martin@loewis.home.cs.tu-berlin.de

> > Please tell me how you implement the above requirement without testing
> > whether NULL has been defined?

> They all define it to exactly the same thing: 0

While you may like that definition, we feel that is the wrong
definition.  You can either, change it to be what we feel is right, or
ignore us.  Your choice.  If you choose to ignore us, you can submit
changes to gcc to try and work around any problems you have, but, in
the end, we may merely reject those patches as the wrong solution.

Good luck.

Re: GCC headers and DJGPP port

[DJ Delorie]

> While you may like that definition, we feel that is the wrong
> definition.

DJGPP is a very old system.  When we made that decision, it was based
on experience building huge C++ programs at Cabletron, and what the
ANSI spec required.  This was way before the whole __null thing.

When gcc added __null, the djgpp lists got a flood of user complaints
because their programs wouldn't compile any more.  We want to avoid
that happening again, or ever.

> You can either, change it to be what we feel is right, or ignore us.

Oh, cut the attitude.  We came here to try to find a solution that we
all could live with, so that we could reduce (or eliminate) all the
problems we have with new gcc releases conflicting with old djgpp
headers.  We've been asking technical questions and giving technical
answers to your questions.  We want to do the right thing.  We just
don't want to harm our users when we do it, or cause a maintenance
nightmare, so we're being careful.  There's no need to get mad at us
because we won't take your opinions as fact without questioning them.

Re: GCC headers and DJGPP port

[Mark Mitchell]

>>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:

    DJ> Oh, cut the attitude.

Agreed, with respect to all parties.

There's no need for sarcasm, insult, or personal attach on this list.

Please keep the discussions technical and professional.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Sun, 23 Jul 2000 13:55:15 -0700 (PDT)
> 
> For this reason, I am against your modification to my
> scheme.  I'd rather simplify it, and risk the bugs, and fix any that
> might arise, than do as you suggest.

My suggestion was for the case that something like a switch to
`configure' was deemed a lesser evil than risking bugs.  If it's the
other way around, I'm with you.

> Take a look at config/*/* and you'll start to see what I mean.

Yes, I think I'm quite familiar with that--how shall I put
it?--magnificent bazaar ;-)

Re: GCC headers and DJGPP port

[Eli Zaretskii]

>   > > From: Mike Stump <mrs@windriver.com>
>   > > Date: Sat, 22 Jul 2000 17:23:25 -0700 (PDT)
>   > > 
>   > > > A similar argument can be made for assert.h, stddef.h, and possibly
>   > > > float.h, but these headers do not cause nearly as much trouble as
>   > > > limits.h.  Limits.h must die.
>   >
>   > Such a change doesn't have to affect all platforms, and doesn't need
>   > to happen in one go.  It could be conditioned on some sommand-line
>   > option to `configure', or be the default on only some platforms, at
>   > least initially.
> No, that's a hack, plain and simple.

I believe it's no more hackyish than --disable-nls or --without-x.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Sun, 23 Jul 2000 15:20:26 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: law@cygnus.com

> I believe I addressed the issues you raised in other messages.  The
> above referred to a suggestion originally made by Mike (to remove
> stddef.h and possibly other headers based on Autoconf test).

It is a modification to the scheme I suggested.  I can support the
scheme I suggested, and I would argue here for it, if it helps you.  I
am happy to do this.  I wasn't going to say anything about the change
to the scheme you suggest, as I think my previous point was clear as
to where I stood on that issue.  I, personally, would not argue for
such a modification.  I'd argue against it.  Now, that doesn't mean
that it can't go in, bear in mind, I am but one member of the list,
just one reader.  In the end, the maintainers (I am not presently one)
make the decisions, based in part on all the concerns and ideas other
might present and of course their experience, knowledge and skill.

The problem is that mirrored configury bits that are just like other
bits, but different is one of the most glaring `bad design' issues in
the compiler that I know.  I support the unification and removal of
the duplicate bits.  By configuring the headers some ways on some
machines and some ways on other machines, I feel we contribute to this
`bad design'.  For this reason, I am against your modification to my
scheme.  I'd rather simplify it, and risk the bugs, and fix any that
might arise, than do as you suggest.

Take a look at config/*/* and you'll start to see what I mean.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Sun, 23 Jul 2000 09:39:13 -0600
> From: Jeffrey A Law <law@cygnus.com>
> 
>   In message < 200007231105.HAA13296@indy.delorie.com >you write:
>   > > From: Mike Stump <mrs@windriver.com>
>   > > Date: Sat, 22 Jul 2000 17:23:25 -0700 (PDT)
>   > > 
>   > > > A similar argument can be made for assert.h, stddef.h, and possibly
>   > > > float.h, but these headers do not cause nearly as much trouble as
>   > > > limits.h.  Limits.h must die.
>   > > 
>   > > If we do this, we should do them all enmass, and then be willing to
>   > > seek out and test on lots of platforms to make sure we don't introduce
>   > > new bugs.
>   > 
>   > Such a change doesn't have to affect all platforms, and doesn't need
>   > to happen in one go.  It could be conditioned on some sommand-line
>   > option to `configure', or be the default on only some platforms, at
>   > least initially.
> No, that's a hack, plain and simple.  And it fails to address the issues I
> pointed out in my previous messages.

I believe I addressed the issues you raised in other messages.  The
above referred to a suggestion originally made by Mike (to remove
stddef.h and possibly other headers based on Autoconf test).

Re: GCC headers and DJGPP port

[Jeffrey A Law]

  In message < 200007231105.HAA13296@indy.delorie.com >you write:
  > > From: Mike Stump <mrs@windriver.com>
  > > Date: Sat, 22 Jul 2000 17:23:25 -0700 (PDT)
  > > 
  > > > A similar argument can be made for assert.h, stddef.h, and possibly
  > > > float.h, but these headers do not cause nearly as much trouble as
  > > > limits.h.  Limits.h must die.
  > > 
  > > If we do this, we should do them all enmass, and then be willing to
  > > seek out and test on lots of platforms to make sure we don't introduce
  > > new bugs.
  > 
  > Such a change doesn't have to affect all platforms, and doesn't need
  > to happen in one go.  It could be conditioned on some sommand-line
  > option to `configure', or be the default on only some platforms, at
  > least initially.
No, that's a hack, plain and simple.  And it fails to address the issues I
pointed out in my previous messages.
jeff

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Sat, 22 Jul 2000 17:30:18 -0700 (PDT)
>
> > 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.
> 
> And is it also much easier for you to test all systems that gcc has
> ever been build for and verify your new patches are right?

I don't know how to reply to that.  Any change can potentially break
something somewhere, and requires testing on all supported platforms.

At the end of the day, I trust you, the GCC maintainers, to draw the
line: to find a reasonable way to make the changes in such a manner
that will minimize the risks for other platforms while still not
causing stagnation.  This includes any guidance and requirements you
might have for us to submit patches in a way that suits your judgement
of the risks on the one hand and the benefits on the other.

However, if the general trend of minimizing the dependencies between
GCC and the system headers, at least in the case of DJGPP, is not
something you are willing to accept, these considerations become a
moot point.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Sat, 22 Jul 2000 17:23:25 -0700 (PDT)
> 
> > A similar argument can be made for assert.h, stddef.h, and possibly
> > float.h, but these headers do not cause nearly as much trouble as
> > limits.h.  Limits.h must die.
> 
> If we do this, we should do them all enmass, and then be willing to
> seek out and test on lots of platforms to make sure we don't introduce
> new bugs.

Such a change doesn't have to affect all platforms, and doesn't need
to happen in one go.  It could be conditioned on some sommand-line
option to `configure', or be the default on only some platforms, at
least initially.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Sat, 22 Jul 2000 15:19:20 -0700 (PDT)
> 
> > If it's okay with you, I'd like to discuss limits.h (and syslimits.h
> > that is related to it) first.  Why is it necessary for GCC to install
> > its own version of this header?
> 
> Wrong question.  I'll answer it anyway, because it is best.  It is
> best, because gcc already knows so much about the target system, that
> it can generate this file.

Nevertheless, I think that system headers are much more closely
related to the library than to the compiler.  Where the compiler needs
something special in the headers to make sure it generates correct
code, it is indeed justified to use compiler-supplied definitions.
But is limits.h such a case, and if so, which part of it,
specifically?

> A way of approaching this, would be to explain to me the problem this
> causes, slowly, so that I can understand the issues, and we can work
> out a solution to the problems encountered.

Our problem with installing GCC headers is that this complicates our
maintenance.  It introduces an additional dependency between GCC
development and DJGPP library development.  Each change in GCC's
headers will potentially require changes in either the library or the
other system headers.  Likewise, changes in system headers or the
library which clash with GCC's headers would be impossible or hard,
even if the conflicts do not indicate real problems.  Use of special
redefinition guards (whose names must be coordinated with GCC's
headers), #include_next, etc.--all this introduces extra complexity
into library maintenance.

Given the scarcity of our resources, we would like to prevent this
friction as much as possible.  We would like to avoid the need for
library maintainers to be aware of all the intricacies of the headers
which come with GCC, including any changes scheduled for the next
release.  The infrequent releases and the nature of our users (see
below) dictate that.

Another dimension of the problem is user support.  The support
provided on comp.os.msdos.djgpp for solving installation and usage
problems is very efficient; most questions are answered within hours,
the rest within a day or two.  This is imperative when dealing with
the kind of clueless newbies that most of our users are--DJGPP is the
first development environment for many of them.

This support quality doesn't come without an effort.  Given that the
ported GCC is distributed as precompiled binaries, making its setup on
any given machine, in any directory, seamless and reliable is not
easy.  It took years of incremental improvements to get where we are
today: you unzip the files, set a single environment variable, and all
the ported packages (not only GCC) start working.

But installation snafus still happen, albeit at a low rate; when they
do, we, the maintainers, need to understand what went wrong in order
to get the user back on track.  Interdependencies between header
files, the critical role of `specs', various add-on packages people
install which come with their own headers--all these already make this
task not easy at all.  Add to this GCC-supplied headers, which might
or might not be installed into the right place, and the user support
becomes much harder.  We would like to avoid that.

Re: GCC headers and DJGPP port

[Zack Weinberg]

On Sat, Jul 22, 2000 at 05:23:25PM -0700, Mike Stump wrote:
> > From: Zack Weinberg <zack@wolery.cumb.org>
> > Date: Sat, 22 Jul 2000 16:02:26 -0700
> > To: Mike Stump <mrs@windriver.com>
> 
> > A similar argument can be made for assert.h, stddef.h, and possibly
> > float.h, but these headers do not cause nearly as much trouble as
> > limits.h.  Limits.h must die.
> 
> If we do this, we should do them all enmass, and then be willing to
> seek out and test on lots of platforms to make sure we don't introduce
> new bugs.

Agreed, this would be a major intrusive change, and would require
heavy testing.

Now seems like a good time to do it, to me - we are working on a new
major version, after all.

zw

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Sat, 22 Jul 2000 18:36:29 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: law@cygnus.com

> > 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 he probably meant tested on all systems in all ways, once by
hand.

Anyway, if we know of classes of reasons why a native stddef.h might
not be what we want to do, we could either fixincludes it or autoconf
and not use it if we don't like 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.

And is it also much easier for you to test all systems that gcc has
ever been build for and verify your new patches are right?  See, being
ok on just your system isn't good enough to do a change...

While we could do it one way on some systems and other ways on other
systems, this creates long term configury hair I think it would be
best to avoid, if we can.

Re: GCC headers and DJGPP port

[Mike Stump]

> From: Zack Weinberg <zack@wolery.cumb.org>
> Date: Sat, 22 Jul 2000 16:02:26 -0700
> To: Mike Stump <mrs@windriver.com>

> A similar argument can be made for assert.h, stddef.h, and possibly
> float.h, but these headers do not cause nearly as much trouble as
> limits.h.  Limits.h must die.

If we do this, we should do them all enmass, and then be willing to
seek out and test on lots of platforms to make sure we don't introduce
new bugs.

Re: GCC headers and DJGPP port

[Zack Weinberg]

On Fri, Jul 21, 2000 at 03:10:09PM -0500, Loren James Rittle wrote:
> In article < 20000720191609.B7661@wolery.cumb.org >:
> 
> > I'd believe we can chuck out a lot of it, not all.  For instance, the
> > BSDs don't run fixincludes, and they have their own stddef.h which
> > ours must match (when we are installed in /usr/local instead of from
> > the BSD unified tree).  And then there's the platforms using
> > fixinc.wrap or fixinc.svr4...
> 
> Hi Zack,
> 
> Libelous comment! ;-) I can only speak authoritatively for FreeBSD
> (although NetBSD appears to configure the same as us): At least in the
> offical GNU CVS archive version (and our official /usr/ports
> collection patches against the 2.95 branch), we now adhered to Jeff
> Law's pronouncement that ports must not disable fixincludes by setting
> USER_H.  It took some work to get there but we are there now.

I stand corrected.  My information is out of date; the last time I
looked closely at any BSD's build process was back in the day of
FreeBSD 3.0.

> I can't speak authoritatively on what happens when the compiler is
> installed as the system compiler.

However, it is this case I was thinking specifically of.  Not so long
ago I had a discussion with someone from FreeBSD over what it would
take to get them to install the system compiler in the same way it
would be installed if you configured the distribution tarball with
--prefix=usr; i.e. with a /usr/lib(exec)/gcc-lib/TARGET/VERSION
directory, and with stddef.h etc. in the /include subdirectory of
that.  I was told, in many more words, that this would never happen.

What that means is, there will always be a /usr/include/stddef.h on a
FreeBSD box, which will not be the header provided by GCC.  But when
GCC is installed in /usr/local, its private stddef.h has to play by
the same rules.  I'm thinking not of the actual definitions of size_t,
etc. when I say "same rules" - but the magic involved with determining
whether or not size_t has already been typedefed.  That magic
constitutes the majority of our stddef.h.

zw

Re: GCC headers and DJGPP port

[Zack Weinberg]

On Sat, Jul 22, 2000 at 03:19:20PM -0700, Mike Stump wrote:
> > If it's okay with you, I'd like to discuss limits.h (and syslimits.h
> > that is related to it) first.  Why is it necessary for GCC to install
> > its own version of this header?
> 
> Wrong question.  I'll answer it anyway, because it is best.  It is
> best, because gcc already knows so much about the target system, that
> it can generate this file.

I'd like to chime in here, because I believe there is a clear case for
dropping <limits.h> from GCC's provided headers, much clearer than any
other header we provide.

Unlike all the other headers we provide, its contents are not solely
dictated by the C standard.  In a freestanding environment, sure, you
can get away with only defining the various TYPE_MAX and _MIN macros.
In an unusual hosted environment that provides nothing but the
features of ISO C, again, we're fine.  But the moment you bring in
POSIX, or XPG, or historical BSD or SysV, or *anything* that extends
the C standard, dozens of values are added to limits.h.

gcc doesn't have enough information to probe for all those values.  It
doesn't even know what they are.  So instead we use #include_next and
<syslimits.h> to get both our limits.h and the system's limits.h
included.  I don't understand the way that mechanism does work, in
fact I would bet that no one does.  I know it doesn't work as it was
intended to; it tries ever so hard not to defeat the multiple include
optimization - and fails.  It's so fragile that it breaks if you
disable the MI optimization - which should be impossible!

And it gains us *nothing*.  The system <limits.h> will have all the
definitions we're trying to provide.  It has to.  All the standards
limits.h might conform to are strict supersets of C89.  C99 adds
values to limits.h, but we don't need to provide them any more than we
need to provide C99 <wchar.h>.  An archaic system like Michael S.'s
4.3BSD might not have it at all - okay, so we can provide a fallback,
or have fixincludes patch in any missing definitions.  But we don't
need to force our header on the majority of systems in common use,
that have perfectly good limits.h already.

A similar argument can be made for assert.h, stddef.h, and possibly
float.h, but these headers do not cause nearly as much trouble as
limits.h.  Limits.h must die.

zw

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Sat, 22 Jul 2000 10:32:55 -0600
> From: Jeffrey A Law <law@cygnus.com>
> 
>   In message < 200007220919.FAA12001@indy.delorie.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.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Sat, 22 Jul 2000 10:10:38 -0600
> From: Jeffrey A Law <law@cygnus.com>
>
> I would love to see this happen too, but I'm not going to agree to install
> changes which are fundamentally wrong

That's why we started this thread--to understand what isn't wrong in
your opinion, so that changes are not rejected after someone has
labored on them.

> such as overriding USER_H.

Sorry, I don't know what USER_H is.  And I don't think we were talking
about using it.  As far as I understood, we were talking about a
configury change that would find out whether certain headers, such as
stddef.h and assert.h, are already provided by the target system, and
if so, refrain from installing GCC's versions.

Would that approach be generally acceptable?

> We also
> have to be practical and realize that DOS is a severely braindamaged system
> and we shouldn't compromise our ability to DTRT on other platforms just to
> make DOS happy.

I don't think anybody wants to compromise GCC's ability on other
platforms.  It is perfectly clear that any DJGPP-related changes
should not hamper other platforms in any way.

In any case, the changes we are discussing have nothing to do with DOS
per se.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Sat, 22 Jul 2000 05:19:10 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> What I am trying to do is help arrive at an acceptable way of solving
> the problem, so that those who will actually do the work would avoid
> submitting patches which will be rejected.

> Is it okay with you to discuss the remaining few headers that are
> relevant to C programs, and see which of them need to be installed by
> GCC and which can be left out?

Sure.  But only on the condition you stated above, that there _is_ in
fact a problem.

> If it's okay with you, I'd like to discuss limits.h (and syslimits.h
> that is related to it) first.  Why is it necessary for GCC to install
> its own version of this header?

Wrong question.  I'll answer it anyway, because it is best.  It is
best, because gcc already knows so much about the target system, that
it can generate this file.

A way of approaching this, would be to explain to me the problem this
causes, slowly, so that I can understand the issues, and we can work
out a solution to the problems encountered.  Also, we cannot solve
problems, without being made aware of them.  I'm not aware of too many
problems that limits.h should cause.  They two biggest problems I see
is that we have a brittle way of handling sizeof(int) == 2 and
sizeof(long)==8, that should be cleaned up and made robust.

Re: GCC headers and DJGPP port

[Phil Edwards]

Jeffrey A Law <law@cygnus.com>:
> Let's take the __null issue again.  According to the C++ standard it is
> an implementation-defined C++ null pointer constant -- it also states
> that (void *)0 is not an acceptable value.
>
> It turns out that using "0" doesn't work, nor does "0L" for reasons I
> can't remember.

Overloading based on the distinction between pointer and integer becomes
impossible, or a freakish nightmare at best.  If you pass in "NULL",
you'd expect the compiler to choose the pointer version, but if it's 0 a
compiler will -- quite correctly -- choose the integer version.

With 0L you can at least hope to get an ambiguity warning.  Sometimes.
Except if the overloaded function takes a long integer, then you're
screwed again.

Having __null magically only match pointer types is an extremely froody
solution, and I'm glad that g++ went that route.


Phil

Re: GCC headers and DJGPP port

[Gabriel Dos Reis]

Jeffrey A Law <law@cygnus.com> writes:

[...]

| Let's take the __null issue again.  According to the C++ standard it is
| an implementation-defined C++ null pointer constant -- it also states
| that (void *)0 is not an acceptable value.
| 
| It turns out that using "0" doesn't work, nor does "0L" for reasons I
| can't remember.

"0" or "0L" might be acceptable, for an appropriate definition of
"acceptable".  However, I'm firmly convinced that GCC's approach is the
way to go, as far as the C++ front-end is concerned.  It enables us to
issue warning when a use of NULL might lead to unintended semantic.
In that regard, GCC is far superior to its competitors.

-- Gaby
CodeSourcery, LLC                             http://www.codesourcery.com

Re: GCC headers and DJGPP port

[Jeffrey A Law]

  In message < 200007220919.FAA12001@indy.delorie.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.  I think you'll find that it's
far easier to just let GCC install the headers it expects and deal with it.

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?

[ Yes, the exception is certain *BSD* systems which mistakenly have overridden
  USER_H for about 7 years and as a result never have made GNU's stddef.h work
  properly with their system. ]

Let's take the __null issue again.  According to the C++ standard it is
an implementation-defined C++ null pointer constant -- it also states
that (void *)0 is not an acceptable value.

It turns out that using "0" doesn't work, nor does "0L" for reasons I
can't remember.

The C++ experts on this list decided the best solution which would
satisfy the C++ standard in a generic way was to define NULL as a builtin
implementation defined C++ constant via __null and have the compiler make
sure it had the right type/value internally.

By not using GNU's stddef.h you're going to get a non-compliant stddef.h.


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.  We fix them, but because you're not installing
the fixed header files your implementation still has whatever non-compliance
issues we found and fixed for GCC's internal header files.

This isn't unlike the systems that didn't run fixincludes because their headers
where "compliant" or didn't install GCC's fixed headers for the same reason.
Well, it turns out most were not compliant because of a bogus
'struct exception' in math.h which GCC knew how to fix and could have made
the header files on those systems compliant.

I'm of the opinion that compliance in header files is never actually achieved,
you just get closer and closer over the years. 

jeff

Re: GCC headers and DJGPP port

[Jeffrey A Law]

  In message < 200007220909.FAA11989@indy.delorie.com >you write:
  > GCC already talks to DOS: we have a working port of GCC since 1989,
  > when DJ Delorie first ported it.  We were tracking the GCC development
  > since then, and I don't think we missed any version (with the
  > exception of the EGCS vs GCC schism period, when we mostly used GCC
  > 2.8.1).  So GCC port is not something that is being born now.
  > 
  > What is different about the next release is that we would like GCC to
  > be built for DJGPP out of the box, with all the necessary quirks
  > integrated into the official GCC distribution.  Until now, building
  > GCC for DJGPP required a few custom changes and special scripts that
  > were not distributed with GCC.  For example, the headers that GCC
  > installs when you say "make install" were ignored--this is the issue
  > we are trying to figure out in this thread.
I would love to see this happen too, but I'm not going to agree to install
changes which are fundamentally wrong, such as overriding USER_H.  We also
have to be practical and realize that DOS is a severely braindamaged system
and we shouldn't compromise our ability to DTRT on other platforms just to
make DOS happy.

jeff

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Fri, 21 Jul 2000 13:51:59 -0700 (PDT)
> 
> Bear in mind, in the end, the only way to make the port work, or to
> test it, will be to download it and try it.

Of course.  It's just that others from the DJGPP team will actually do
that.

What I am trying to do is help arrive at an acceptable way of solving
the problem, so that those who will actually do the work would avoid
submitting patches which will be rejected.

Perhaps I should have explained that to begin with.

Is it okay with you to discuss the remaining few headers that are
relevant to C programs, and see which of them need to be installed by
GCC and which can be left out?

My information indicates that the relevant headers are: assert.h,
stddef.h, iso646.h, limits.h, stdbool.h, and syslimits.h.

I understand that cxxabi.h, exception, new, new.h, and typeinfo are
for C++ programs, and I think that varargs.h and stdarg.h should come
with the compiler, as they are closely related to compiler built-ins.
I also understand that you agree that we send patches which would cause
GCC not to install stddef.h, assert.h, and iso646.h, as the following
quote from your earlier message indicates:

> Bottom line, If you want to do up patches to autoconf for stddef.h,
> assert.h and iso646.h and not install them if the system already has
> them, I'd invite you to, I don't think anyone will argue to keep them.
> Before we do this, I'd like a person like drepper to buy into it as
> well, though I don't think he'll mind.

If it's okay with you, I'd like to discuss limits.h (and syslimits.h
that is related to it) first.  Why is it necessary for GCC to install
its own version of this header?

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Fri, 21 Jul 2000 19:49:18 +0100 (GMT)
> From: Mo McKinlay <mmckinlay@gnu.org>
> 
> It seems to me that the DJGPP group are going about this back-to-front -
> trying to figure out how to change gcc in order to work with the
> libc. Because of gcc's nature, it seems to me that this approach is almost
> doomed to fail from the start.

Sorry, I don't follow: what led you to this conclusion?  Perhaps you
could elaborate a bit more.  Specifically, why is this approach
back-to-front, and what is it in GCC's nature which goes against this
approach?

> It's inevitable that a new release of the DJGPP libc will come about at
> the same time that DJGPP's gcc is integrated with the main tree - trying
> to prevent would be foolhardy, I think. 

This, too, is a conclusion which evades me.  For the past few years,
the releases of DJGPP library and of the ported GCC were perfectly
unsynchronized.  I don't see why it should be different with the next
GCC release.

(It's not that we are actively preventing synchronization between GCC
and DJGPP; it's just that the resources and free time of people who
work on both these projects happen to be different.)

> - Take a sample platform/libc. I'll cite glibc 2.1 on i686-pc-linux-gnu
>   for this, as it's the platform I know best.
> 
> - Examine the headers the libc installs/uses. Knowing both glibc and
>   DJGPP's libc *reasonably* well, it should be reasonably trivial to
>   spot glaring differences in how things are handled (i.e., placement
>   of definitions, what things like NULL are defined to, what definitions
>   are wrapped with).

I don't think this approach is practical at this time.  DJGPP is a
very old system, and it is presently mostly in maintenance phase.  New
features are added, but not at a fast rate, and they never change the
structure of the library in any significant manner: back compatibility
and infrequent releases dictate this.  Given the available resources,
I don't believe such a serious change would ever happen.

> - Rework DJGPP's libc's headers to follow these semantics

From what little I know about glibc, following its headers means much
more than changes in headers alone.

>   and run a
>   testsuite on the libc (I assume you guys *have* a testsuite for the
>   libc, right? :)

Yes, we do have a test suite.  But no test suite can ever find all the
serious problems.  At least ours doesn't, as was proven in the past.
(We have improved the test suite since then, but we are not naive
enough to believe it now covers everything.)

There a difference between running a test suite and building a large
body of industry-strength packages such as all the GNU packages ported
to DJGPP, especially since each DJGPP port typically drags a
Unix-centric package, screaming and kicking, into a DOS/Windows world
which is totally alien to the original code.

> Once that's done, you have a new libc release - one that works both with
> the current DJGPP gcc and with future gcc releases (3.x, 4.x, who knows?),
> and you can start making gcc itself talk GO32/DOS.

GCC already talks to DOS: we have a working port of GCC since 1989,
when DJ Delorie first ported it.  We were tracking the GCC development
since then, and I don't think we missed any version (with the
exception of the EGCS vs GCC schism period, when we mostly used GCC
2.8.1).  So GCC port is not something that is being born now.

What is different about the next release is that we would like GCC to
be built for DJGPP out of the box, with all the necessary quirks
integrated into the official GCC distribution.  Until now, building
GCC for DJGPP required a few custom changes and special scripts that
were not distributed with GCC.  For example, the headers that GCC
installs when you say "make install" were ignored--this is the issue
we are trying to figure out in this thread.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Geoff Keating <geoffk@cygnus.com>
> Date: 21 Jul 2000 11:33:58 -0700
> 
> Note that:
> - size_t is defined by stdio.h and stddef.h and string.h and wchar.h;
> - NULL is defined by stdio.h and stddef.h and string.h and time.h and wchar.h;
> - wchar_t is defined by stdlib.h and stddef.h and wchar.h;
> 
> so you already have to test if NULL is defined before defining it.

Not if every definition of NULL says the same.  This is allowed by
ANSI/ISO C (AFAIK), and GCC quite rightfully doesn't print any warnings.

As for size_t and wchar_t, we have a private header that defines them,
which is included by all the headers that need those types.  There are
safeguards to prevent multiple typedefs.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Fri, 21 Jul 2000 03:52:39 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> I cannot look into the include directory of the next compiler
> release: I don't have the CVS tree on my machine, as I'm not one of
> the maintainers of the DJGPP port of GCC; and I don't know enough
> about GCC internals to efficiently look for the information anyway.
> If I could look at the headers instead of asking, I would, believe
> me.

Bear in mind, in the end, the only way to make the port work, or to
test it, will be to download it and try it.  I incorrectly assumed
the state of things, sorry.

Re: GCC headers and DJGPP port

[Loren James Rittle]

In article < 20000720191609.B7661@wolery.cumb.org >:

> I'd believe we can chuck out a lot of it, not all.  For instance, the
> BSDs don't run fixincludes, and they have their own stddef.h which
> ours must match (when we are installed in /usr/local instead of from
> the BSD unified tree).  And then there's the platforms using
> fixinc.wrap or fixinc.svr4...

Hi Zack,

Libelous comment! ;-) I can only speak authoritatively for FreeBSD
(although NetBSD appears to configure the same as us): At least in the
offical GNU CVS archive version (and our official /usr/ports
collection patches against the 2.95 branch), we now adhered to Jeff
Law's pronouncement that ports must not disable fixincludes by setting
USER_H.  It took some work to get there but we are there now.

When the compiler is installed in /usr/local, fixincludes is run!

I can't speak authoritatively on what happens when the compiler is
installed as the system compiler.

Regards,
Loren
-- 
Loren J. Rittle
Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Re: GCC headers and DJGPP port

[Mo McKinlay]

Please excuse my hurling of this in at this point..

As a developer using both GCC on Solaris, FreeBSD Linux, as well as DJGPP
on MS-DOS and Cygwin under Win32, I've been following this thread with
interest.

It seems to me that the DJGPP group are going about this back-to-front -
trying to figure out how to change gcc in order to work with the
libc. Because of gcc's nature, it seems to me that this approach is almost
doomed to fail from the start.

It's inevitable that a new release of the DJGPP libc will come about at
the same time that DJGPP's gcc is integrated with the main tree - trying
to prevent would be foolhardy, I think. 

I would've thought the best course of action to take would be to:

- Take a sample platform/libc. I'll cite glibc 2.1 on i686-pc-linux-gnu
  for this, as it's the platform I know best.

- Examine the headers the libc installs/uses. Knowing both glibc and
  DJGPP's libc *reasonably* well, it should be reasonably trivial to
  spot glaring differences in how things are handled (i.e., placement
  of definitions, what things like NULL are defined to, what definitions
  are wrapped with). 

- Rework DJGPP's libc's headers to follow these semantics, and run a
  testsuite on the libc (I assume you guys *have* a testsuite for the
  libc, right? :)

At which point, you've sorted your libc headers problem, provided nothing
breaks. If it does, figure out why it breaks, and fix it.

Once that's done, you have a new libc release - one that works both with
the current DJGPP gcc and with future gcc releases (3.x, 4.x, who knows?),
and you can start making gcc itself talk GO32/DOS.

That still leaves binutils, but I think that's sorted already, isn't it?

Again, if I'm out of line, I apologise, but I think it was something worth
saying.

Of course, feel free to point out if I've missed something glaringly
obvious [apologies if I have].

Mo.

-- 
Mo McKinlay             Chief Software Architect         inter/open Labs
mmckinlay (at) gnu.org                                http://www.gnu.org

Re: GCC headers and DJGPP port

[Geoff Keating]

DJ Delorie <dj@delorie.com> writes:

> > I don't know what your copy of stdio.h looks like, however, it
> > should certainly test whether NULL is defined before defining it.
> 
> It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
> NULL.  I have a philosophical problem with anyone saying "it should
> certainly test it" because it means that, at the whim of the gcc team,
> we'd need to add yet another test to our standard headers because yet
> another symbol was absconded by the gcc headers.  Where does it end?
> Do we have to wrap every single #define in all the system headers?
> Will we have to wrap the function prototypes also?

Note that:
- size_t is defined by stdio.h and stddef.h and string.h and wchar.h;
- NULL is defined by stdio.h and stddef.h and string.h and time.h and wchar.h;
- wchar_t is defined by stdlib.h and stddef.h and wchar.h;

so you already have to test if NULL is defined before defining it.

Actually, the best way to do this is to put this in, say, string.h:

/* Get size_t and NULL from <stddef.h>.  */
#define	__need_size_t
#define	__need_NULL
#include <stddef.h>

and then you don't have to care what the compiler does, your library
will work.  A similar technique can be used in stdio.h to implement
vfprintf without defining va_arg.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Fri, 21 Jul 2000 17:26:47 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> I can understand that there is additional contents in your limits.h. I
> fail to see what this has to do with GCC installing its own copy of
> limits.h into a gcc directory. It is common in GCC installations to
> have multiple copies of limits.h, and chain them together with
> #include_next. This works very well on other GCC ports (e.g. Linux,
> Solaris) - why doesn't it work on DJGPP?

#include_next does work, but it requires various #ifdef's to protect
it from multiple redefinitions, and these #ifdef's introduce special
reserved symbols that make maintenance harder.  Where this is
necessary, it is done, but we would like to make the number of such
headers as small as possible.

I think if we discuss each of the headers that GCC currently installs,
we could come to a reasonable compromise as to what can go and what
needs to stay.

> Forcing GCC not to install certain headers does not minimize
> problems.

It does minimize the potential for a new GCC version to break existing
code due to incompatible definitions in the headers distributed with
GCC.

> Instead, if a new feature in GCC requires support in header
> files, your port would break as your libraries would not provide that
> support.

This is a different problem, one which we are more willing to risk
having.  If a new feature cannot be used until the library is
upgraded, that's semi-okay, since that new feature didn't exist
previously.  But if a new release of the compiler breaks code which
worked before that, that is a much more serious problem.

Re: GCC headers and DJGPP port

[Marc Espie]

In article < 200007201205.OAA15361@loewis.home.cs.tu-berlin.de > you write:
>> > I had hoped you could have concluded that it either does or
>> > does not break the library.

>> We couldn't do that because we had no information on how __null works
>> in the C++ compiler.  If we missed something in the docs, please tell
>> where we should have read about it.

>It is not in the texinfo documentation, as it is not intended to be
>used by anybody then the "implementation" itself (which consists of
>the compiler, and the standard library). There is a note in cp/NEWS
>you may not have seen, though.

This is wrong.
Quoting from the documentation:

   This manual documents how to run, install and port the GNU compiler,
as well as its new features and incompatibilities, and how to report
bugs.  It corresponds to GCC version 2.96.

There *is* a place in the documentation for this kind of details.
Knowing about __null and what it entails may be very useful when
porting gcc to a new architecture, or making it work in system-specific
implementations, where you tend to muck with --nostdinc and other such
switches.

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> For example, the headers installed by GCC use various macros to avoid
> redefinitions and multiple typedefs.  Using these headers means that
> the library developers need to know about all of these special macros,
> lest some change in the library breaks them.  Likewise, the GCC port
> maintainers need to know about all the subtleties of the library
> internals, to prevent changes in GCC headers from breaking the
> library.

There is a technical need that the compiler proper and its header
files agree on certain things, so there will be some overlap. It's not
the overlap that hurts, but the fact that there is disagreement what
each header must provide and what it must not provide. If we can agree
on an interface, danger of breaking things between releases will be
smaller.

Regards,
Martin

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> > PLEASE identify real problems caused by the actual contents of these
> > files, instead of merely reporting your imagination that there could
> > be problems.
> 
> Some of the definitions on these headers are private to the library.
> For example, math.h defines HUGE_VAL to a runtime constant
> __dj_huge_val.  limits.h defines several constants such as
> _POSIX_PATH_MAX that are specific to the library implementation.
> These are just a few examples.

I can understand that there is additional contents in your limits.h. I
fail to see what this has to do with GCC installing its own copy of
limits.h into a gcc directory. It is common in GCC installations to
have multiple copies of limits.h, and chain them together with
#include_next. This works very well on other GCC ports (e.g. Linux,
Solaris) - why doesn't it work on DJGPP?

> So we must try to minimize the problems in released versions,
> including problems that can happen when a new version of GCC is
> released which wasn't available at the time the library was
> developed and tested.

Forcing GCC not to install certain headers does not minimize
problems. Instead, if a new feature in GCC requires support in header
files, your port would break as your libraries would not provide that
support.

If you arrange that the DJGPP port follows the conventions of most
other ports, the danger of breaking things is smallest.

Regards,
Martin

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Thu, 20 Jul 2000 17:16:17 -0700 (PDT)
> 
> > Hence our desire to do the Right Thing yet avoid such disasters for
> > our users.
> 
> Actually, about the only way to avoid that, is taking a more active
> role in gcc, testing snapshots, reporting new problems that crop up,
> submitting fixes that arise.

We are doing this as best as we can.  But the DJGPP development team
is evidently too small and too hard-pressed for free time, to catch
all the problems before they sneak into released versions.  Thus our
desire to prevent potential problems before they have a chance to
happen.

We think that keeping the number (and contents) of the headers that
come with GCC to the bare minimum is a step towards that goal.

> In this case, a fixincludes chunk is the standard way to correct this
> problem (until such time as a new release of the library comes out to
> solve it).

It might be.  However, preventing the problems from happening in the
first place is even better, so we would like to pursue that, too.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Thu, 20 Jul 2000 14:44:39 -0700 (PDT)
> 
> > > > Could you tell what other headers do we need to consider?
> > > 
> > > I'd rather tell you how to find the compiler include directories
> > > (touch t.c && gcc -v t.c), and how to run ls (dir).
> 
> > The question was about future GCC releases, for which I cannot
> > simply look in my include directories.
> 
> Don't worry about that future.  It will come and you can't stop it.
> Good, bad or indifferent.  What we can worry about it what is most
> likely to be in the next release.

The next release *is* one of what I called ``future releases''.  That
is what I was talking about; I'm sorry if that was unclear.  Please
understand that English is not my first language; I don't always catch
such fine nuances.

> This can be answered by looking in the compiler's include
> directory, just as I said.

I cannot look into the include directory of the next compiler release:
I don't have the CVS tree on my machine, as I'm not one of the
maintainers of the DJGPP port of GCC; and I don't know enough about
GCC internals to efficiently look for the information anyway.  If I
could look at the headers instead of asking, I would, believe me.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Thu, 20 Jul 2000 13:25:40 -0700 (PDT)
> 
> You have three options, either submit the work to make them more
> independent, submit the work to make gcc agree, or don't make them
> work together (no work).  Let me know which option you want to pursue
> and I can help you.

The first option, of course.  I apologize if I managed to confuse
things so that it wasn't clear.

Could we please go back to discussing the headers that GCC currently
wants to install, one by one, and see what needs to be done to get to
a more independent setup?

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Thu, 20 Jul 2000 14:05:06 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> However, I thought you are *maintainers* of the compiler
> (specifically, the DOS port of it).

See, that's the whole point: DJGPP library and the GCC port are
developed and maintained by different people.  There's some overlap,
but we have found it unrealistic to require that the same people
understand all the subtleties of each of these two complex projects
(there are also others: Binutils, GDB, etc.) and closely track the
development of all of them.  We would like to make the individual
ports and the library to be as independent of each other as we can.

This means we need to try to prevent potential problems before they
happen, because we cannot afford frequent releases.  Having many
headers that are developed and tested separately by the GCC team goes
against this.

For example, the headers installed by GCC use various macros to avoid
redefinitions and multiple typedefs.  Using these headers means that
the library developers need to know about all of these special macros,
lest some change in the library breaks them.  Likewise, the GCC port
maintainers need to know about all the subtleties of the library
internals, to prevent changes in GCC headers from breaking the
library.

This is what we are trying to avoid.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Thu, 20 Jul 2000 13:15:06 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> >   - errno.h
> >   - limits.h
> >   - assert.h
> >   - math.h
> >   - stddef.h
> > 
> > These all include definitions and declarations that are intimately
> > related to the libc internals.
> 
> I still can't understand why you feel threatened by a file name.

Not by a file name, by its contents.

> PLEASE identify real problems caused by the actual contents of these
> files, instead of merely reporting your imagination that there could
> be problems.

Some of the definitions on these headers are private to the library.
For example, math.h defines HUGE_VAL to a runtime constant
__dj_huge_val.  limits.h defines several constants such as
_POSIX_PATH_MAX that are specific to the library implementation.
These are just a few examples.

Of course, with suitable #ifdef'ing, it's possible to prevent each
conflict as it happens.  But we would like to avoid the need for this
additional maintenance effort where we can.  DJGPP is maintained by a
small group of volunteers; we cannot afford frequent releases.  So
we must try to minimize the problems in released versions, including
problems that can happen when a new version of GCC is released which
wasn't available at the time the library was developed and tested.

Re: GCC headers and DJGPP port

[Zack Weinberg]

On Thu, Jul 20, 2000 at 12:29:45PM -0700, Bruce Korb wrote:
> Zack Weinberg wrote:
> 
> > The vast majority of the complexity of stddef.h has to do with how it
> > interacts with system-provided headers.  Not on the actual definition
> > of size_t, etc. but on the interlock mechanism which prevents
> > duplicate typedefs.  And I don't think fixincludes is prepared to help
> > with that.  It would need a huge table recording the appropriate
> > interlock to use for each platform.
> 
> No.  Actually, fixincludes has always "fixed" the headers
> that typedef these by wrapping them as I described.  What would
> happen if someone #include-d stddef.h before another system
> header that typedefed the same thing?  Nothing bad only because
> fixincludes was there first and wrapped the duplicate typedef.
> Since this has already been done, and since you can rely on it,
> it seems that the complexity is unnecessary, yes?

Are you certain that fixincludes does this thing for every platform
that might have problems, to every header that might have problems?

I'd believe we can chuck out a lot of it, not all.  For instance, the
BSDs don't run fixincludes, and they have their own stddef.h which
ours must match (when we are installed in /usr/local instead of from
the BSD unified tree).  And then there's the platforms using
fixinc.wrap or fixinc.svr4...

> > I might also add that some modern C libraries, such as glibc, know
> > exactly which headers are provided by gcc and do not have their own
> > copies.

glibc expects gcc to provide stddef.h, and includes it dozens of times
with special __need_something macros defined.  It expects gcc to
provide limits.h, and engages in mutual #include recursion between its
own limits.h and ours.

As I understand it, those are two of the three headers we're
discussing dropping where possible - the other being assert.h.  And I
am all for this idea, but we need to pay close attention to how it's
done.

zw

Re: GCC headers and DJGPP port

[DJ Delorie]

> Actually, about the only way to avoid that, is taking a more active
> role in gcc, testing snapshots, reporting new problems that crop up,
> submitting fixes that arise.

I believe we're doing this.  The problem is that djgpp releases
are so infrequent (one per year or two)

> In this case, a fixincludes chunk is the standard way to correct this
> problem (until such time as a new release of the library comes out to
> solve it).

I recall that at the time, using fixincludes under DOS simply wasn't
an option.  Perhaps this new fixincludes will show more promise for
us.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Thu, 20 Jul 2000 19:51:14 -0400
> From: DJ Delorie <dj@delorie.com>
> To: mrs@windriver.com

> Hence our desire to do the Right Thing yet avoid such disasters for
> our users.

Actually, about the only way to avoid that, is taking a more active
role in gcc, testing snapshots, reporting new problems that crop up,
submitting fixes that arise.  I don't know that any other solution
actually works in theory or practice.  :-(

In this case, a fixincludes chunk is the standard way to correct this
problem (until such time as a new release of the library comes out to
solve it).

Re: GCC headers and DJGPP port

[DJ Delorie]

> ?  Can you elaborate?  Is this just the #undef/the changing your
> headers to match gcc's headers problem?

DJGPP's headers all unconditionally defined NULL to be 0, without
testing if it was already defined.  Because the definitions were
identical, such testing wasn't needed.  However, when gcc first
introduced the __null concept, it *also* added such definitions to the
libstdc++ headers, defining NULL to be __null.

Users who #included a libstdc++ header first, then #included something
like <stdio.h>, would see errors from cpp because stdio.h would
attempt to #define NULL to something different than it already was.

At that time, we chose to simply add an #undef in our headers to stop
the user complaints, because (1) it was expedient, (2) we didn't
understand __null enough to warrant that it wouldn't break us, and (3)
doing that was within our power.

Hence our desire to do the Right Thing yet avoid such disasters for
our users.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Thu, 20 Jul 2000 19:18:59 -0400
> From: DJ Delorie <dj@delorie.com>
> To: mrs@windriver.com

> When gcc added __null, the djgpp lists got a flood of user complaints
> because their programs wouldn't compile any more.

?  Can you elaborate?  Is this just the #undef/the changing your
headers to match gcc's headers problem?

Re: GCC headers and DJGPP port

[DJ Delorie]

> > It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
> > NULL.  
>
> so it is not all that clear that it is provided by stdio.h
> exclusively.

I didn't say exclusively.  I said stdio.h provides it.  Headers that
expect stdio.h to *relinquish* its provision of NULL are broken.  The
other djgpp headers that also provide NULL cooperate so that none of
them have to relinquish their provisions to the others.

> Please tell me how you implement the above requirement without testing
> whether NULL has been defined?

They all define it to exactly the same thing: 0

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Thu, 20 Jul 2000 02:41:28 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > From: Mike Stump <mrs@windriver.com>
> > Date: Wed, 19 Jul 2000 14:35:28 -0700 (PDT)
>
> If you mean that we should submit patches to the GCC maintainers to
> fix the headers installed by GCC, then that's a maintenance burden
> we would like to avoid, at least for the headers that there's no
> real need for GCC to install.

I have given you three options in my other message, let me know which
path you wish to take, and I will be able to help you with the above.

> Date: Thu, 20 Jul 2000 02:44:16 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > From: Mike Stump <mrs@windriver.com>
> > Date: Wed, 19 Jul 2000 14:44:15 -0700 (PDT)
> >
> > > Could you tell what other headers do we need to consider?
> > 
> > I'd rather tell you how to find the compiler include directories
> > (touch t.c && gcc -v t.c), and how to run ls (dir).

> The question was about future GCC releases, for which I cannot
> simply look in my include directories.

Don't worry about that future.  It will come and you can't stop it.
Good, bad or indifferent.  What we can worry about it what is most
likely to be in the next release.  This can be answered by looking in
the compiler's include directory, just as I said.

> > errno.h limits.h proto.h varargs.h assert.h exception math.h
> > stdarg.h syslimits.h curses.h fixed new stdbool.h typeinfo
> > cxxabi.h iso646.h new.h stddef.h

> Are all of these relevant for C programs?

No.

> Ideally, I'd like to get rid of all of the above-mentioned headers
> except varargs.h and stdarg.h.  What would we (the DJGPP
> maintainers) need to do to come as close as possible to that goal?

Submit patches, and be right and be willing to back it.

> Date: Thu, 20 Jul 2000 06:24:10 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: martin@loewis.home.cs.tu-berlin.de

> What is of interest to us is what will a C function see when called
> with a __null argument from a C++ program.  This is required to DTRT
> in C headers so that they would work with C++ programs regardless of
> the order of headers inclusion (since some headers in libstdc++
> define NULL).

Do you actually expect the compiler is so broken such that the answer
would be anything other than NULL?  It is not so broken, nor has it
ever been.  You could have easily asked the compiler this as well, if
you cared.

> Date: Thu, 20 Jul 2000 10:37:16 -0400
> From: DJ Delorie <dj@delorie.com>
> To: djgpp-workers@delorie.com

> > I don't know what your copy of stdio.h looks like, however, it
> > should certainly test whether NULL is defined before defining it.

> It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
> NULL.

Gosh, my copy of a C standard says:

       53. The macro NULL  is  defined  in  <stddef.h>  as  a  null
           pointer constant; see 7.1.6.

Can you explain this?  Do other C langauge standards not have this?
Which ones?

> I have a philosophical problem with anyone saying "it should
> certainly test it" because it means that, at the whim of the gcc
> team, we'd need to add yet another test to our standard headers
> because yet another symbol was absconded by the gcc headers.

Or, maybe it is for another reason, like a hard requirement of some
language standard?

> Where does it end?  Do we have to wrap every single #define in all
> the system headers?  Will we have to wrap the function prototypes
> also?

The sky is falling...  Don't worry, it is not.  Trust us.
If you find a bit of misplaced sky, just tell us, submit a patch to
fix it, and the world continues on.

Re: GCC headers and DJGPP port

[Michael Meissner]

On Thu, Jul 20, 2000 at 10:42:29PM +0200, Martin v. Loewis wrote:
> Please tell me how you implement the above requirement without testing
> whether NULL has been defined?

Speaking as somebody who was there when the original decision was made, it was
the intention of the committee that you either:

   1)	Include a null.h include file that defines NULL, possibly having null.h
	being protected by #ifndef/#endif (IIRC, this was actually discussed,
	but it would be logical to do so);

   2)	Use #ifndef/#endif around the definition;

   3)	Define NULL using exactly the same spelling in each include file, in
	which case it would fall under the rule that identical redefinitions of
	macros using the same spelling are not treated as redefinitions.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> > I don't know what your copy of stdio.h looks like, however, it
> > should certainly test whether NULL is defined before defining it.
> 
> It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
> NULL.  

According to ISO C99, NULL is provided by the following headers

locale.h (7.11)
stddef.h (7.17)
stdio.h  (7.19)
stdlib.h (7.20)
string.h (7.21)
time.h   (7.23)
wchar.h  (7.24)

so it is not all that clear that it is provided by stdio.h
exclusively.

> I have a philosophical problem with anyone saying "it should
> certainly test it" because it means that, at the whim of the gcc team,
> we'd need to add yet another test to our standard headers because yet
> another symbol was absconded by the gcc headers.

Please tell me how you implement the above requirement without testing
whether NULL has been defined?

Regards,
Martin

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Thu, 20 Jul 2000 02:42:48 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > From: Mike Stump <mrs@windriver.com>
> > Date: Wed, 19 Jul 2000 14:38:04 -0700 (PDT)
> > 
> I'm not sure what GCC's notion of NULL are you talking about.

gcc only has one definition of NULL.  After you read it, it was my
hope you would understand it.  If you don't, you might trye
comp.lang.c.

> We cannot use __null in C headers unconditionally,

Ok, I already know that.  You must misunderstand my point if you think
I said that.

> Use of __null conditioned on __cplusplus is questionable,

At this point, I will just say trust me, do it.  You can either ignore
me, or listen to me, your choice.

> since libc.a is not compiled with that definition of NULL.  Am I
> missing something?

Yes.

> > Sprinkle in #undef NULL if you get redefinition errors.
>  
> We did use #undef to solve the immediate problem, but it looked like a
> brute-force and potentially dangerous (for C++ programs) solution.  I
> wonder if there's a better one.

No.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Thu, 20 Jul 2000 02:41:28 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > From: Mike Stump <mrs@windriver.com>
> > Date: Wed, 19 Jul 2000 14:35:28 -0700 (PDT)
>
> If you mean that we should submit patches to the GCC maintainers to
> fix the headers installed by GCC, then that's a maintenance burden we
> would like to avoid, at least for the headers that there's no real
> need for GCC to install.

> In other words, we would like to make the DJGPP library development
> as independent from GCC development as possible, so that there would
> be no immediate need to release a new library version every time a
> new version of GCC is released, and no need for the users to
> download a new GCC version each time a new library release is out.

You have three options, either submit the work to make them more
independent, submit the work to make gcc agree, or don't make them
work together (no work).  Let me know which option you want to pursue
and I can help you.  I am confused, as I don't yet know which route
you hacve decided to pursue.

Re: GCC headers and DJGPP port

[Bruce Korb]

Zack Weinberg wrote:
> As I said, __SIZE_TYPE__ et al are magic defines, built into cpp.  You
> must have missed this chunk of cppinit.c:
> 
> static const struct builtin builtin_array[] =
> {
>   /* ... */
> #ifndef NO_BUILTIN_SIZE_TYPE
>   C("__SIZE_TYPE__",            SIZE_TYPE),

Ah, that is very different.  Never mind  :-).
It was not what I was expecting, so it was not what I saw.

> I do not know why stddef.h has default definitions of these macros;
> perhaps in case a non-GCC compiler ever used our stddef.h.

Now *that* is curious.  Some of the headers also force an error
if the compiler is not GCC...

> The vast majority of the complexity of stddef.h has to do with how it
> interacts with system-provided headers.  Not on the actual definition
> of size_t, etc. but on the interlock mechanism which prevents
> duplicate typedefs.  And I don't think fixincludes is prepared to help
> with that.  It would need a huge table recording the appropriate
> interlock to use for each platform.

No.  Actually, fixincludes has always "fixed" the headers
that typedef these by wrapping them as I described.  What would
happen if someone #include-d stddef.h before another system
header that typedefed the same thing?  Nothing bad only because
fixincludes was there first and wrapped the duplicate typedef.
Since this has already been done, and since you can rely on it,
it seems that the complexity is unnecessary, yes?

> I might also add that some modern C libraries, such as glibc, know
> exactly which headers are provided by gcc and do not have their own
> copies.
??

Re: GCC headers and DJGPP port

[Zack Weinberg]

On Thu, Jul 20, 2000 at 10:27:09AM -0700, Bruce Korb wrote:
> Zack Weinberg wrote:
> > 
> > On Thu, Jul 20, 2000 at 08:25:40AM -0700, Bruce Korb wrote:
> > ...
> > > The amusing thing about that is that stddef.h is not platform
> > > specific, even though the SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE
> > > defines are.  I'm thinking that fixincludes should do its thing
> > > on the GCC-supplied stddef.h since fixincludes replaces these
> > > typedefs with platform-specific changes (as of today :-).
> > 
> > Our stddef.h uses the magic __SIZE_TYPE__, __PTRDIFF_TYPE__, and
> > __WCHAR_TYPE__ defines, which are set by cpp to the values of the
> > SIZE_TYPE, etc. defines in tm.h.  And fixincludes should too.
> 
> fixincludes did not ever do so, prior to today, that is.  :-)
> I grepped the CVS source for stddef.h and found absolutely no
> reference to "__PTRDIFF_TYPE__", except the three below.  Also,
> there was no reference to "PTRDIFF_TYPE" at all, period.

As I said, __SIZE_TYPE__ et al are magic defines, built into cpp.  You
must have missed this chunk of cppinit.c:

static const struct builtin builtin_array[] =
{
  /* ... */
#ifndef NO_BUILTIN_SIZE_TYPE
  C("__SIZE_TYPE__",            SIZE_TYPE),
#endif
#ifndef NO_BUILTIN_PTRDIFF_TYPE
  C("__PTRDIFF_TYPE__",         PTRDIFF_TYPE),
#endif
#ifndef NO_BUILTIN_WCHAR_TYPE
  C("__WCHAR_TYPE__",           WCHAR_TYPE),
#endif
};

SIZE_TYPE, WCHAR_TYPE, and PTRDIFF_TYPE come from tm.h.  If a port
defines one of the NO_BUILTIN_* macros, then it is required to set the
corresponding __*_TYPE__ macro in its specs.  This is done for
e.g. powerpc, where the correct values depend on -m switches.

I do not know why stddef.h has default definitions of these macros;
perhaps in case a non-GCC compiler ever used our stddef.h.

The vast majority of the complexity of stddef.h has to do with how it
interacts with system-provided headers.  Not on the actual definition
of size_t, etc. but on the interlock mechanism which prevents
duplicate typedefs.  And I don't think fixincludes is prepared to help
with that.  It would need a huge table recording the appropriate
interlock to use for each platform.

I might also add that some modern C libraries, such as glibc, know
exactly which headers are provided by gcc and do not have their own
copies.

zw

Re: GCC headers and DJGPP port

[Bruce Korb]

Zack Weinberg wrote:
> 
> On Thu, Jul 20, 2000 at 08:25:40AM -0700, Bruce Korb wrote:
> ...
> > The amusing thing about that is that stddef.h is not platform
> > specific, even though the SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE
> > defines are.  I'm thinking that fixincludes should do its thing
> > on the GCC-supplied stddef.h since fixincludes replaces these
> > typedefs with platform-specific changes (as of today :-).
> 
> Our stddef.h uses the magic __SIZE_TYPE__, __PTRDIFF_TYPE__, and
> __WCHAR_TYPE__ defines, which are set by cpp to the values of the
> SIZE_TYPE, etc. defines in tm.h.  And fixincludes should too.

fixincludes did not ever do so, prior to today, that is.  :-)
I grepped the CVS source for stddef.h and found absolutely no
reference to "__PTRDIFF_TYPE__", except the three below.  Also,
there was no reference to "PTRDIFF_TYPE" at all, period.

> #ifndef _GCC_PTRDIFF_T
>   ...
> #ifndef __PTRDIFF_TYPE__
> #define __PTRDIFF_TYPE__ long int
> #endif
> typedef __PTRDIFF_TYPE__ ptrdiff_t;
> #endif /* _GCC_PTRDIFF_T */

Notice the hard-wired define to "long int".  Not good.
I would suggest the following:

1.  If a target has a stddef.h, use it, filtered through fixincludes.
2.  If not, provide one -- *ALSO* filtered through fixincludes
3.  In the provided one, replace all the SIZE_T, WCHAR_T and PTRDIFF_T
    junk with:

      typedef DUMMY ptrdiff_t;
      typedef DUMMY size_t;
      typedef DUMMY wchar_t;

    allowing fixincludes to clean it up in a platform-specific manner.
    The fixed result would look like any other fixup of these typedefs
    that fixinc does.  viz.:

      #ifndef __PTRDIFF_TYPE__
      #define __PTRDIFF_TYPE__ XXX
      #endif
      #if !defined(_GCC_PTRDIFF_T)
      #define _GCC_PTRDIFF_T
      typedef __PTRDIFF_TYPE__ ptrdiff_t;
      #endif

      #ifndef __SIZE_TYPE__
      #define __SIZE_TYPE__ YYY
      #endif
      #if !defined(_GCC_SIZE_T)
      #define _GCC_SIZE_T
      typedef __SIZE_TYPE__ size_t;
      #endif

      #ifndef __WCHAR_TYPE__
      #define __WCHAR_TYPE__ ZZZ
      #endif
      #if !defined(_GCC_WCHAR_T) && ! defined(__cplusplus)
      #define _GCC_WCHAR_T
      typedef __WCHAR_TYPE__ wchar_t;
      #endif

    except that the `XXX', `YYY', and `ZZZ' would be the strings
    obtained from the "tm.h" header file inclusion.

> I sent in a patch over a year ago that drastically simplified our
> stddef.h, but no one ever reviewed it.
> http://gcc.gnu.org/ml/gcc-patches/1999-01/msg00655.html .

This should be simpler, still ;-)

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Thu, 20 Jul 2000 08:25:40 -0700
> From: Bruce Korb <bkorb@sco.COM>
> 
> The worst one *is* NULL.  The reason is that there are so bloody
> many platforms out there that define it in all manner of random places.
> I assume you know that.  GCC has to adapt itself to all these platforms.

Sorry, I don't see why does GCC need to adapt itself.  Does this need
arise when building GCC, or when using it (or both)?

And what problems are caused by the fact that NULL is defined in many
places?  Are you talking about platforms which don't have NULL defined
in the usual places, such as stddef.h?  If so, I think the platforms
which do have NULL defined where it should be, should not be punished
on behalf of the non-conforming platforms.

> > Of course, a working fixincludes might circumvent the technical
> > problems.
> 
> I'm ready to help, but I don't have a DOS platform to play on.

You don't need to have a DOS machine, any Windows 9X or NT machine, or
even Linux with DOSEmu, will do: DJGPP supports all these platforms.
You could even try this on Unix, if you only use Posix functions like
popen, system, and dup.

Please don't misunderstand me: I'm not saying that you *should* do
this yourself, I'm saying that you _can_ do this should you wish to.

Re: GCC headers and DJGPP port

[Zack Weinberg]

On Thu, Jul 20, 2000 at 08:25:40AM -0700, Bruce Korb wrote:
...
> The amusing thing about that is that stddef.h is not platform
> specific, even though the SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE
> defines are.  I'm thinking that fixincludes should do its thing
> on the GCC-supplied stddef.h since fixincludes replaces these
> typedefs with platform-specific changes (as of today :-).

Our stddef.h uses the magic __SIZE_TYPE__, __PTRDIFF_TYPE__, and
__WCHAR_TYPE__ defines, which are set by cpp to the values of the
SIZE_TYPE, etc. defines in tm.h.  And fixincludes should too.

I sent in a patch over a year ago that drastically simplified our
stddef.h, but no one ever reviewed it.
http://gcc.gnu.org/ml/gcc-patches/1999-01/msg00655.html .

zw

Re: GCC headers and DJGPP port

[Bruce Korb]

DJ Delorie wrote:
> 
> > I don't know what your copy of stdio.h looks like, however, it
> > should certainly test whether NULL is defined before defining it.
> 
> It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
> NULL.  I have a philosophical problem with anyone saying "it should
> certainly test it" because it means that, at the whim of the gcc team,
> we'd need to add yet another test to our standard headers because yet
> another symbol was absconded by the gcc headers.  Where does it end?

The worst one *is* NULL.  The reason is that there are so bloody
many platforms out there that define it in all manner of random places.
I assume you know that.  GCC has to adapt itself to all these platforms.
fixincludes will no longer wrap #defines of NULL in the presence
of either "#if.*NULL" or a "#undef NULL".  It also always wraps the
typedefs for size_t, ptrdiff_t and wchar_t.  It does this on the 
assumption that they will be provided by GCC-supplied stddef.h.
The amusing thing about that is that stddef.h is not platform
specific, even though the SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE
defines are.  I'm thinking that fixincludes should do its thing
on the GCC-supplied stddef.h since fixincludes replaces these
typedefs with platform-specific changes (as of today :-).

> Of course, a working fixincludes might circumvent the technical
> problems.

I'm ready to help, but I don't have a DOS platform to play on.
(Don't really want one, either. ;)  The fork(2) and pipe(2) calls
can be gotten around with temporary files and system(3).

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: "Mark E." <snowball3@bigfoot.com>
> Date: Thu, 20 Jul 2000 09:24:11 -0400
> 
> > > In any case, the following headers out of the above list seem
> > > especially dangerous:
> > > 
> > >   - errno.h
> > >   - limits.h
> > >   - assert.h
> > >   - math.h
> 
> These are fixincluded headers. Or at least they aren't in the replacement 
> header directory. Don't worry about these.

Perhaps I misunderstood: someone (either Mike or Martin) said that
stddef.h and assert.h, at least, are installed by the compiler.

If that is not true, this is a non-issue.  I apologize for any
confusion I might have caused.

> > >   - stddef.h
> > > 
> This one is along with:
> iso646.h
> stdarg.h
> stdbool.h
> varargs.h

I think varargs.h and stdarg.h will have to be taken from GCC.
I think Mike said that stddef.h can be left out (on platforms
which already have it).

This leaves us with iso646.h and stdbool.h.  Ideally, I'd like
these not to be installed by GCC, either, to avoid interdependencies
between the GCC and DJGPP library distributions, even though
these two headers are relatively harmless.

Re: GCC headers and DJGPP port

[DJ Delorie]

> I don't know what your copy of stdio.h looks like, however, it
> should certainly test whether NULL is defined before defining it.

It doesn't.  It shouldn't have to.  ANSI says that stdio.h provides
NULL.  I have a philosophical problem with anyone saying "it should
certainly test it" because it means that, at the whim of the gcc team,
we'd need to add yet another test to our standard headers because yet
another symbol was absconded by the gcc headers.  Where does it end?
Do we have to wrap every single #define in all the system headers?
Will we have to wrap the function prototypes also?

Of course, a working fixincludes might circumvent the technical
problems.

Re: GCC headers and DJGPP port

[Mark E.]

> > In any case, the following headers out of the above list seem
> > especially dangerous:
> > 
> >   - errno.h
> >   - limits.h
> >   - assert.h
> >   - math.h

These are fixincluded headers. Or at least they aren't in the replacement 
header directory. Don't worry about these.

> >   - stddef.h
> > 
This one is along with:
iso646.h
stdarg.h
stdbool.h
varargs.h

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> > I had hoped you could have concluded that it either does or
> > does not break the library.
> 
> We couldn't do that because we had no information on how __null works
> in the C++ compiler.  If we missed something in the docs, please tell
> where we should have read about it.

It is not in the texinfo documentation, as it is not intended to be
used by anybody then the "implementation" itself (which consists of
the compiler, and the standard library). There is a note in cp/NEWS
you may not have seen, though.

However, I thought you are *maintainers* of the compiler
(specifically, the DOS port of it). So if you had a long discussion,
why didn't you ask on gcc@gcc.gnu.org, or look at the source code to
see what __null does, or consult the ChangeLogs to find out who
installed that change, and contacted the author?

> I explained the technical reasons in a message I sent today.  If it
> didn't yet reach you, soon it will.  If I still failed to explain
> something, please tell what needs further explanation.

I've looked through all your messages so far, and I could only find
one problem: redefinition of NULL. Although this would be certainly a
bug, I'm not all that clear how that could ever happen. You wrote

>> The problem is with C++ programs that include <stdio.h> or <cstdio>
>> (or stddef.h etc.)  after C++ headers such as <libio.h>: these
>> define NULL, and GCC then complains about its redifinition.

I don't know what your copy of stdio.h looks like, however, it should
certainly test whether NULL is defined before defining it. So in this
case, I'd say there is a bug in <stdio.h>.

It may be that there is also a bug in the program: No program should
include <libio.h>; instead, it should always include <stdio.h>, or
<iostream>.

If there were further problems, please tell me as I may have missed
them in all these messages.

> What is of interest to us is what will a C function see when called
> with a __null argument from a C++ program.  

What do you mean by "will see"? At run-time, the value on the stack
will be a 0x00000000 bit pattern for the parameter, at least on 32-bit
machines.

Regards,
Martin

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> I'm not sure what GCC's notion of NULL are you talking about.  We
> cannot use __null in C headers unconditionally, because it will cause
> unresolved externals in C programs, right?

Wrong. As there is no declaration of __null, and as this is not a
function, it will cause a compile error, not an unresolved symbol.

> Use of __null conditioned on __cplusplus is questionable, since
> libc.a is not compiled with that definition of NULL.  Am I missing
> something?

Yes. Please re-read my message elaborating on __null semantics. Usage
of __null does not result in an assembler-level reference to a symbol
named __null; there is no such symbol. As a result, libc.a does not
need to provide anything.

Instead, cc1plus will emit 'zero' immediate values in assembler,
depending on the assembler language (e.g. clearing eax).

> We did use #undef to solve the immediate problem, but it looked like a
> brute-force and potentially dangerous (for C++ programs) solution.  I
> wonder if there's a better one.

Yes. Try to trust the GCC-provided headers more than you currently do.

Regards,
Martin

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> In any case, the following headers out of the above list seem
> especially dangerous:
> 
>   - errno.h
>   - limits.h
>   - assert.h
>   - math.h
>   - stddef.h
> 
> These all include definitions and declarations that are intimately
> related to the libc internals.

I still can't understand why you feel threatened by a file name.
PLEASE identify real problems caused by the actual contents of these
files, instead of merely reporting your imagination that there could
be problems.

Regards,
Martin

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> The problem that triggered this thread is that GCC installs its own
> versions of some of those headers, which conflict with our system
> headers.

Let me take this from a different angle: Why exactly do these cause
conflicts? What exactly is the conflict? Please be as specific as
possible, e.g. providing a code example that works with only your
headers installled and breaks when ours are present (also indicate the
nature of breakage).

> In other words, we would like to make the DJGPP library development
> as independent from GCC development as possible, so that there would
> be no immediate need to release a new library version every time a new
> version of GCC is released, and no need for the users to download a
> new GCC version each time a new library release is out.

The best way to achieve this is to have gcc use the gcc-supplied
headers. Their exact contents is mandated by the ISO C standard, so
there is no need for you to change anything about it in the next ten
years. Just rely on gcc providing them, and be done.

Regards,
Martin

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Thu, 20 Jul 2000 09:29:35 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> > Seriously, though: the conclusion was that we didn't like the
> > redefinition of NULL in C++ headers (see my other message for the
> > problems this causes).
> 
> So you had all this discussion to agree on a mental state (you don't
> like it)?

No, we actually acted on that (by blocking redefinition of NULL in the
C headers).

> I had hoped you could have concluded that it either does or
> does not break the library.

We couldn't do that because we had no information on how __null works
in the C++ compiler.  If we missed something in the docs, please tell
where we should have read about it.

> Please try to be technical instead of political - especially if you
> are asking the same from GCC developers!

I thought I was technical.  I explained the technical reasons in a
message I sent today.  If it didn't yet reach you, soon it will.  If
I still failed to explain something, please tell what needs further
explanation.

> It's very easy. In C++, NULL is an "implementation-defined C++ null
> pointer constant", according to 18.1, [lib.support.types]/4. That
> means, "possible definitions include 0 and 0L, but not (void*)0".

Thank you for this information.

What is of interest to us is what will a C function see when called
with a __null argument from a C++ program.  This is required to DTRT
in C headers so that they would work with C++ programs regardless of
the order of headers inclusion (since some headers in libstdc++ define
NULL).

Re: GCC headers and DJGPP port

[Martin v. Loewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

> > > Anyway, one reason that __null might cause trouble is that it breaks
> > > previous versions of the library which were compiled with different
> > > definition of NULL.  I think we've been discussing that on the DJGPP
> > > developers list to death.
[...]
> Seriously, though: the conclusion was that we didn't like the
> redefinition of NULL in C++ headers (see my other message for the
> problems this causes).

So you had all this discussion to agree on a mental state (you don't
like it)? I had hoped you could have concluded that it either does or
does not break the library. If it does break the library, exactly why?
If it does not break the library, what is the problem?

Please try to be technical instead of political - especially if you
are asking the same from GCC developers!

> But we couldn't understand why does the C++ compiler redefines NULL
> in its headers, so we couldn't find a solution that would satisfy us
> all and avoid breaking the C++ compiler at the same time.  Perhaps
> you could help.

It's very easy. In C++, NULL is an "implementation­defined C++ null
pointer constant", according to 18.1, [lib.support.types]/4. That
means, "possible definitions include 0 and 0L, but not (void*)0".

If you define NULL as 0, you find that

#include <stdlib.h>
void foo(int);
void foo(int*);

int main()
{

  foo(NULL);
}

will compile flawlessly and invoke the first function, even though it
is probably the author probably meant to express a pointer. The reason
is that passing 0 into an int is an exact match, whereas converting it
to int* is a conversion. Please note that the exact meaning of this
program could depend on the platform - if the parameter is a typedef
that is "long int" on some systems and "int" on others, the meaning of
this program changes.

The same problem exists with

  throw NULL;

which does not do what the user would expect (i.e. it throws an int,
or long - not a null pointer). There are a few more common program
mistakes involving a misunderstanding of NULL. Those can only be
detected if the compiler *knows* that this used to be NULL, hence the
__null keyword.

I believe this feature of g++ has proven useful, and I'd certainly
expect that all ports of g++ support it.

Regards,
Martin

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Wed, 19 Jul 2000 14:44:15 -0700 (PDT)
>
> > Could you tell what other headers do we need to consider?
> 
> I'd rather tell you how to find the compiler include directories
> (touch t.c && gcc -v t.c), and how to run ls (dir).

The question was about future GCC releases, for which I cannot simply
look in my include directories.  I didn't want to waste your time by
arguing about problems that were already resolved.  For example, I
understand that it was decided to remove limits.h from the list of
installed headers in future GCC releases.

> errno.h limits.h proto.h varargs.h assert.h exception math.h stdarg.h
> syslimits.h curses.h fixed new stdbool.h typeinfo cxxabi.h iso646.h
> new.h stddef.h

Are all of these relevant for C programs?  exception, fixed, new,
typeinfo, cxxabi.h, and new.h seem to be for C++.  (I don't care about
C++ headers, since DJGPP uses the GNU version of libstdc++, and so no
conflicts should be caused by using GCC's C++-related headers.)

Ideally, I'd like to get rid of all of the above-mentioned headers
except varargs.h and stdarg.h.  What would we (the DJGPP maintainers)
need to do to come as close as possible to that goal?

In any case, the following headers out of the above list seem
especially dangerous:

  - errno.h
  - limits.h
  - assert.h
  - math.h
  - stddef.h

These all include definitions and declarations that are intimately
related to the libc internals.

I don't know what does proto.h include, but if it only defines the P_
macro for portable prototype declarations, it won't hurt.

As for syslimits.h, we don't have this header, so it should not be a
problem, unless it is included by varargs.h, stdarg.h, or some other
header that will be installed by GCC.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Wed, 19 Jul 2000 14:38:04 -0700 (PDT)
> 
> > Date: Wed, 19 Jul 2000 14:26:25 -0400 (EDT)
> > From: Eli Zaretskii <eliz@delorie.com>
> > To: martin@loewis.home.cs.tu-berlin.de
> 
> > Seriously, though: the conclusion was that we didn't like the
> > redefinition of NULL in C++ headers (see my other message for the
> > problems this causes).  But we couldn't understand why does the C++
> > compiler redefines NULL in its headers, so we couldn't find a
> > solution that would satisfy us all and avoid breaking the C++
> > compiler at the same time.  Perhaps you could help.
> 
> Sure, change all definitions of NULL to more closely match gcc's
> notion of null, and you're done.

I'm not sure what GCC's notion of NULL are you talking about.  We
cannot use __null in C headers unconditionally, because it will cause
unresolved externals in C programs, right?  Use of __null conditioned
on __cplusplus is questionable, since libc.a is not compiled with that
definition of NULL.  Am I missing something?

> Sprinkle in #undef NULL if you get redefinition errors.
 
We did use #undef to solve the immediate problem, but it looked like a
brute-force and potentially dangerous (for C++ programs) solution.  I
wonder if there's a better one.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Wed, 19 Jul 2000 14:35:28 -0700 (PDT)
> 
> Worrying isn't useful.  Verify that they are accurate and
> don't cause problems and be done with it.  If there are bugs in them,
> fix them, submit the patches to fix them, and be done with it.

Sorry, I'm not sure I understand.

The DJGPP system headers are maintained by the DJGPP project.  These
headers are perfectly okay, they don't need any fixing.

The problem that triggered this thread is that GCC installs its own
versions of some of those headers, which conflict with our system
headers.

If you mean that we should submit patches to the GCC maintainers to
fix the headers installed by GCC, then that's a maintenance burden we
would like to avoid, at least for the headers that there's no real
need for GCC to install.

In other words, we would like to make the DJGPP library development
as independent from GCC development as possible, so that there would
be no immediate need to release a new library version every time a new
version of GCC is released, and no need for the users to download a
new GCC version each time a new library release is out.

Re: GCC headers and DJGPP port

[Bruce Korb]

Mike Stump wrote:
> Sure, change all definitions of NULL to more closely match gcc's
> notion of null, and you're done.  Sprinkle in #undef NULL if you get
> redefinition errors.

That would be prudent  :-).  If fixincl is ever activated
and the #undef is not present, it will go through and "fix"
the problem.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Wed, 19 Jul 2000 14:26:49 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > and other headers I think we'd need to talk about specifically and
> > weigh the issues.

> Could you tell what other headers do we need to consider?

I'd rather tell you how to find the compiler include directories
(touch t.c && gcc -v t.c), and how to run ls (dir).

When I do this on my system, I get:

errno.h limits.h proto.h varargs.h assert.h exception math.h stdarg.h
syslimits.h curses.h fixed new stdbool.h typeinfo cxxabi.h iso646.h
new.h stddef.h

but some of those are fixincluded, and these aren't all the
directories.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Wed, 19 Jul 2000 14:26:25 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: martin@loewis.home.cs.tu-berlin.de

> Seriously, though: the conclusion was that we didn't like the
> redefinition of NULL in C++ headers (see my other message for the
> problems this causes).  But we couldn't understand why does the C++
> compiler redefines NULL in its headers, so we couldn't find a
> solution that would satisfy us all and avoid breaking the C++
> compiler at the same time.  Perhaps you could help.

Sure, change all definitions of NULL to more closely match gcc's
notion of null, and you're done.  Sprinkle in #undef NULL if you get
redefinition errors.

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Wed, 19 Jul 2000 14:25:53 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: martin@loewis.home.cs.tu-berlin.de

> Yes, the actual problem is that GCC installs its headers in a way
> that cause them to be used before the system headers.  A related
> problem is that GCC uses its own versions of stddef.h, limits.h, and
> other headers instead of the system headers when GCC is built.  We
> were worried that using headers that are different from the system
> headers might produce buggy GCC binaries, due to conflicts with
> libc.a against which the native DJGPP port is linked.

Worrying isn't useful.  Verify that they are accurate and
don't cause problems and be done with it.  If there are bugs in them,
fix them, submit the patches to fix them, and be done with it.

Re: GCC headers and DJGPP port

[Mike Stump]

> From: Joe Buck <jbuck@racerx.synopsys.com>
> To: lauras@softhome.net (Laurynas Biveinis)
> Date: Wed, 19 Jul 2000 08:24:23 -0700 (PDT)

> Wouldn't it break the SunOS4 port, or other ports where we're
> bootstrapping from an ancient K&R environment and the C library
> is highly nonstandard?

> (I suppose stddef.h could be omitted only on the platforms where it
> causes problems.)

You must have missed were I talked about autoconfing it, and including
it in environments that don't otherwise already have one, and not
including it otherwise.  By eject, I don't mean outright removal in
100% of the cases.  If 100% of the systems already have stddef.h that
work well, then we could remove it entirely.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Joe Buck <jbuck@racerx.synopsys.com>
> Date: Wed, 19 Jul 2000 08:24:23 -0700 (PDT)
> 
> Wouldn't it break the SunOS4 port, or other ports where we're
> bootstrapping from an ancient K&R environment and the C library
> is highly nonstandard?

If the system is probed at configure time for headers, as Mike
suggested, we could arrange for the headers to be installed on such
systems.  Would this be an okay solution?

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Tue, 18 Jul 2000 20:35:44 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> I'm not talking about C, I'm talking about C++. If djgpp does not use
> __null for NULL, then it can't have the features that g++ has on other
> systems.

Sorry, my wording was inaccurate and misleading.  The problem is with
C++ programs that include <stdio.h> or <cstdio> (or stddef.h etc.)
after C++ headers such as <libio.h>: these define NULL, and GCC then
complains about its redifinition.

> I'm confused what question you are asking. Are you asking why GCC
> installs its headers?

It seems there has been a misunderstanding; I apologize for whatever
part of it that I'm responsible for.

Yes, the actual problem is that GCC installs its headers in a way that
cause them to be used before the system headers.  A related problem is
that GCC uses its own versions of stddef.h, limits.h, and other
headers instead of the system headers when GCC is built.  We were
worried that using headers that are different from the system headers
might produce buggy GCC binaries, due to conflicts with libc.a against
which the native DJGPP port is linked.

Our impression was that these two issues are connected, and that GCC
wants both to be built and used with its own versions of some of the
system headers.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Tue, 18 Jul 2000 20:46:05 -0700 (PDT)
> 
> Well, I reviewed stddef.h, as it is one of the culprits.  After
> reading it, I came to the conclusion that we can probably eject it
> from the compiler safely.

That is wonderful news!  Thanks.

> We can even autoconf the target headers, and provide it, if the target
> doesn't (to be backward compatible with systems that didn't have it
> because of gcc), and to not provide it, if the target system has one.

Yes, I think this should be the best solution, that would avoid
breaking systems which need the version of the headers that GCC
supplies.

> The other headers, like varargs.h, might as well be in the compiler.
> The compiler has to be able to generate code, assuming it does this,
> it _must_ know about the varargs mechanism.  Because it already must
> know about it, it doesn't require any more information to have gcc
> provide stdarg.h and varargs.h, because the compiler generates them,
> they are consistent with the compiler, and cannot be wrong (experts
> need not correct me, I know this is a lie).

I think I understand why stdarg.h and varargs.h need to come with the
compiler.  Are there any other headers that are in that category?  I
think not, but maybe I'm missing something.

If only the va_* macros need to be defined by the compiler
distribution, I think it should be very easy to modify DJGPP system
headers to use them instead of our versions (or in addition to them,
if the need arises).

> Bottom line, If you want to do up patches to autoconf for stddef.h,
> assert.h and iso646.h and not install them if the system already has
> them, I'd invite you to, I don't think anyone will argue to keep them.

Yes, I think this is what we would like to do.

> Before we do this, I'd like a person like drepper to buy into it as
> well, though I don't think he'll mind.

Ulrich, could you please comment on this?

> varargs.h, I think we should reject

Agreed.

> and other headers I think we'd need to talk about specifically and
> weigh the issues.

Could you tell what other headers do we need to consider?

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Tue, 18 Jul 2000 21:13:22 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> > Anyway, one reason that __null might cause trouble is that it breaks
> > previous versions of the library which were compiled with different
> > definition of NULL.  I think we've been discussing that on the DJGPP
> > developers list to death.
> 
> And did these discussions come to a conclusion, or did everybody die
> before that?

You are talking to a few survivors ;-).

Seriously, though: the conclusion was that we didn't like the
redefinition of NULL in C++ headers (see my other message for the
problems this causes).  But we couldn't understand why does the C++
compiler redefines NULL in its headers, so we couldn't find a solution
that would satisfy us all and avoid breaking the C++ compiler at the
same time.  Perhaps you could help.

Re: GCC headers and DJGPP port

[Joe Buck]

> Mike Stump wrote:
> > Well, I reviewed stddef.h, as it is one of the culprits.  After
> > reading it, I came to the conclusion that we can probably eject it
> > from the compiler safely.  It does seem like there is little reason to
> > have it in the compiler, better to be apart of newlib, of glibc, and
> > then all the complexity of it, and the heartache it causes, goes
> > away, permanently.
> 
> I like this idea. Any objections?

Wouldn't it break the SunOS4 port, or other ports where we're
bootstrapping from an ancient K&R environment and the C library
is highly nonstandard?

(I suppose stddef.h could be omitted only on the platforms where it
causes problems.)

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

"Martin v. Loewis" wrote:
> And did these discussions come to a conclusion, or did everybody die
> before that? If there was a conclusion, can you summarize why __null
> might break previous versions of the library?

There wasn't any conclusion then.

Laurynas

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Mike Stump wrote:
> Well, I reviewed stddef.h, as it is one of the culprits.  After
> reading it, I came to the conclusion that we can probably eject it
> from the compiler safely.  It does seem like there is little reason to
> have it in the compiler, better to be apart of newlib, of glibc, and
> then all the complexity of it, and the heartache it causes, goes
> away, permanently.

I like this idea. Any objections?

Laurynas

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Tue, 18 Jul 2000 04:10:45 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: martin@loewis.home.cs.tu-berlin.de

> > NULL is defined as __null on all platforms now

> Not in DJGPP.  __null causes trouble in C programs.

The definition I was talking about does not.

> And yes, we did read all the threads in GCC archives that appear to
> be relevant, and we did discuss them at length.  But we still do not
> understand the technical considerations that caused GCC to insist on
> installing its own headers.  Please help us understand this.

Well, I reviewed stddef.h, as it is one of the culprits.  After
reading it, I came to the conclusion that we can probably eject it
from the compiler safely.  It does seem like there is little reason to
have it in the compiler, better to be apart of newlib, of glibc, and
then all the complexity of it, and the heartache it causes, goes
away, permanently.

We can even autoconf the target headers, and provide it, if the target
doesn't (to be backward compatible with systems that didn't have it
because of gcc), and to not provide it, if the target system has one.

The other headers, like varargs.h, might as well be in the compiler.
The compiler has to be able to generate code, assuming it does this,
it _must_ know about the varargs mechanism.  Because it already must
know about it, it doesn't require any more information to have gcc
provide stdarg.h and varargs.h, because the compiler generates them,
they are consistent with the compiler, and cannot be wrong (experts
need not correct me, I know this is a lie).

Not, all libcs can replicate varargs, but why force them to?  What
good is it?

Another example of a header we can eject is assert.h.  I don't see a
good reason for it to stay in gcc anymore.  Sure, gcc can provide
it, if the system is unwilling, but that should be rare (and rarer
as time goes on).

> Date: Tue, 18 Jul 2000 04:11:53 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: mrs@windriver.com

> > From: Mike Stump <mrs@windriver.com>
> > Date: Mon, 17 Jul 2000 14:28:17 -0700 (PDT)
> > 
> > Simple, gcc knows the target system, including details that affect
> > these things.  Does it mean that gcc has to know a bit about target
> > system, sure.

> GCC should have no problems knowing a bit about a target system: it
> just needs to include the system headers for that.  It's all there.

#inlcuding varargs.h doesn't help gcc generate varargs code.

> This is *exactly* the point: no matter how much we read and re-read
> the relevant discussions in GCC archives, we could _not_ understand
> why there's a need for __null in C programs.

Of course not.  There is no need.

> > varargs.h, is another good example.  Ours works, it'll always
> > work, we prefer it, why not use it?  Is your version safe with
> > -fstrict-aliasing?  Are you sure?  By using ours, we know ours is.

> Are you sure your version doesn't break the library?  I don't think
> you can be sure of that, unless you really studied the internals of
> that particular library.

?  I am at a complete loss as to what to say to this.  Explain how
varargs.h could break the library.  I don't understand how it could.

> IMHO, it is the business of library maintainers to make sure their
> definitions work correctly.  While suggesting to use GCC's
> definitions is nice, they should not be _forced_ on the library,
> because there's a slight chance that the library maintainers can
> indeed get it right on their own.

Sure, they can.  But why should they duplicate the work and hair of
varargs.h?  There is a slight chance that the compiler vendor can
indeed get it right on their own.

> In other words, the possibility that system headers might not work
> right is IMHO not a valid technical reason to force a library to use
> different definitions.  GCC should simply assume that the system
> headers work, and if they don't, tell the maintainers to get them
> right.

Your experience dealing with system vendors differs from our
experience dealing with vendors.

> To: Eli Zaretskii <eliz@is.elta.co.il>
> From: Geoff Keating <geoffk@cygnus.com>
> Date: 18 Jul 2000 09:37:01 -0700

> > I already posted a response: size_t and the rest *are* known at build
> > time: they are defined in the system headers.  GCC could simply use
> > them to build itself.

> It can't do that because your headers might conflict with the
> headers on the system that GCC is being built for.  I'm sure you're
> not trying to claim that someone can include both your <stddef.h>
> and the one on Solaris at the same time...

?  This is a non-issue.  The target compiler never includes
/usr/include, so no conflict is in fact possible.



Bottom line, If you want to do up patches to autoconf for stddef.h,
assert.h and iso646.h and not install them if the system already has
them, I'd invite you to, I don't think anyone will argue to keep them.
Before we do this, I'd like a person like drepper to buy into it as
well, though I don't think he'll mind.

varargs.h, I think we should reject, and other headers I think we'd
need to talk about specifically and weigh the issues.

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> Is __null a builtin in the C compiler?

Not in the C compiler, only in the C++ compiler

> Anyway, one reason that __null might cause trouble is that it breaks
> previous versions of the library which were compiled with different
> definition of NULL.  I think we've been discussing that on the DJGPP
> developers list to death.

And did these discussions come to a conclusion, or did everybody die
before that? If there was a conclusion, can you summarize why __null
might break previous versions of the library?

> > + #undef SIZE_TYPE
> > + #define SIZE_TYPE "long unsigned int"
> 
> Do I understand correctly that this should go into GCC distribution?

Yes, in the target header files.

> If so, I don't think I mind too much.  It does introduce a dependency
> between the library and the compiler, which is unfortunate.  I think
> we need to discuss this on the DJGPP devlopers' list.

It doesn't introduce the dependency, the dependency is already there.

Regards,
Martin

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> > GCC needs to know exactly what size_t and wchar_t is
> 
> This knowledge is accessible to GCC at build time, in the system
> headers.

No. That won't work in a cross-compiler, and it is not possible to
exactly reconstruct a typedef. For example, on some targets, the size
of a type might vary depending on some target options. On those
systems, the gcc-provided header files would change
accordingly. Clearly, when gcc is *compiled*, only one of these
settings is accessible.

Besides, this is not where gcc currently draws this information from,
so it is not accessible in the sense that there is no code in gcc to
access it.

> > NULL is defined as __null on all platforms now
> 
> Not in DJGPP.  __null causes trouble in C programs.

I'm not talking about C, I'm talking about C++. If djgpp does not use
__null for NULL, then it can't have the features that g++ has on other
systems.

> Why does it need to know that without seeing target header files?  

Well, in theory, it wouldn't need to know - but then it wouldn't be
gcc anymore. What is the problem with having that knowledge in gcc?

> The issue that started this thread is that the DJGPP maintainers don't
> understand the _technical_ reasons why should there be any need for
> GCC to insist on its own, possibly incompatible, definitions.  

If they are incompatible, then the port is broken.

> That is what we are asking to explain.  It is most probable that,
> once we understand the technical issues involved, a number of
> plausible solutions could be suggested.

Well, one reason certainly is that gcc currently does not work this
way, and that it would be a lot of work to change it, and that none of
the regular contributors is going to change it in that direction. So
if you want gcc to work in a different way, you'd have to provide
patches - not only for your target, but for all other targets as well.

> And yes, we did read all the threads in GCC archives that appear to be
> relevant, and we did discuss them at length.  But we still do not
> understand the technical considerations that caused GCC to insist on
> installing its own headers.

I'm confused what question you are asking. Are you asking why GCC
installs its headers? I haven't discussed this question in this
message - I thought you are asking why gcc needs builtin knowledge
about the exact definition of certain types and constants.

Regards,
Martin

Re: GCC headers and DJGPP port

[Geoff Keating]

Eli Zaretskii <eliz@delorie.com> writes:

> I already posted a response: size_t and the rest *are* known at build
> time: they are defined in the system headers.  GCC could simply use
> them to build itself.

It can't do that because your headers might conflict with the headers
on the system that GCC is being built for.  I'm sure you're not trying
to claim that someone can include both your <stddef.h> and the one on
Solaris at the same time...

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: GCC headers and DJGPP port

[Geoff Keating]

Laurynas Biveinis <lauras@softhome.net> writes:

> Eli Zaretskii wrote:
> > The problem is that we (the DJGPP maintainers) don't understand why
> > should the headers need to be ``fixed''.  As far as we know, they are
> > just fine.
> 
> This raises one more sensitive issue - remember 'minimizing the FAQs'?
> Our <stdio.h> uses va_list, at least this will be changed by fixincludes.

That's because it's wrong.  Under ISO C, stdio.h is not allowed to
define va_list.  The following is a strictly conforming C program:

#define va_list ha ha ha you lose
#include <stdio.h>
int main(void)
{
  return 0;
}

stdio.h only defines three types (outside the reserved namespaces):
size_t, FILE, and fpos_t.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Tue, 18 Jul 2000 10:57:42 +0200
> From: Laurynas Biveinis <lauras@softhome.net>
> 
> Eli Zaretskii wrote:
> > > GCC needs to know exactly what size_t and wchar_t is
> > 
> > This knowledge is accessible to GCC at build time, in the system
> > headers.
> 
> What about build system != target system?

I wasn't talking about that issue.  I don't understand why would this
be a problem in the cross build as well (GCC has both hosted and
target headers, and can take appropriate actions), but if it is, it's
possible to have different behavior in each case.  For example, GCC
could refrain from installing its own headers in the native case only.

> > > NULL is defined as __null on all platforms now
> > 
> > Not in DJGPP.  __null causes trouble in C programs.
> 
> I have trouble understanding why, if __null is a builtin.

Is __null a builtin in the C compiler?

Anyway, one reason that __null might cause trouble is that it breaks
previous versions of the library which were compiled with different
definition of NULL.  I think we've been discussing that on the DJGPP
developers list to death.

> (And why
> does it cause trouble on DJGPP, but not on other systems?)

I don't know enough about other systems to comment on that.

> Eli, is it a big difference for us, does GCC get definition from djgpp
> header, or from GCC target description one with Mark's patch?
> 
> + #undef SIZE_TYPE
> + #define SIZE_TYPE "long unsigned int"

Do I understand correctly that this should go into GCC distribution?
If so, I don't think I mind too much.  It does introduce a dependency
between the library and the compiler, which is unfortunate.  I think
we need to discuss this on the DJGPP devlopers' list.

> > And yes, we did read all the threads in GCC archives that appear to be
> > relevant, and we did discuss them at length.  But we still do not
> > understand the technical considerations that caused GCC to insist on
> > installing its own headers.  Please help us understand this.

> Uhm, how would you qualify following response:
> > Wrong. GCC needs to know exactly what size_t and wchar_t is, and it
> > must also provide the definition of NULL. size_t must be known so the
> > builtin functions can be declared properly. wchar_t must be known so
> > wide string literals can be emitted correctly. NULL is defined as
> > __null on all platforms now, so that overloading works correctly in
> > C++ (for C, it is something different).

I already posted a response: size_t and the rest *are* known at build
time: they are defined in the system headers.  GCC could simply use
them to build itself.

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Eli Zaretskii wrote:
> I'm not sure I understand what you are saying: what would fixincludes
> do with va_list in stdio.h?  And why would that be a Good Thing (tm)?

IIRC, it would replaced with _VA_LIST from GCC's stdarg.h or something 
like that to ensure ISO conformance. This time I won't judge, is it a 
Good Thing or not.

Laurynas

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Tue, 18 Jul 2000 10:57:40 +0200
> From: Laurynas Biveinis <lauras@softhome.net>
> 
> Eli Zaretskii wrote:
> > The problem is that we (the DJGPP maintainers) don't understand why
> > should the headers need to be ``fixed''.  As far as we know, they are
> > just fine.
> 
> This raises one more sensitive issue - remember 'minimizing the FAQs'?
> Our <stdio.h> uses va_list, at least this will be changed by fixincludes.

I'm not sure I understand what you are saying: what would fixincludes
do with va_list in stdio.h?  And why would that be a Good Thing (tm)?

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Eli Zaretskii wrote:
> The problem is that we (the DJGPP maintainers) don't understand why
> should the headers need to be ``fixed''.  As far as we know, they are
> just fine.

This raises one more sensitive issue - remember 'minimizing the FAQs'?
Our <stdio.h> uses va_list, at least this will be changed by fixincludes.

Laurynas

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Eli Zaretskii wrote:
> > GCC needs to know exactly what size_t and wchar_t is
> 
> This knowledge is accessible to GCC at build time, in the system
> headers.

What about build system != target system?

> > NULL is defined as __null on all platforms now
> 
> Not in DJGPP.  __null causes trouble in C programs.

I have trouble understanding why, if __null is a builtin. (And why
does it cause trouble on DJGPP, but not on other systems?)

> > there is no question *that* gcc must know about
> > these types even without seeing a single target header file.
> 
> Why does it need to know that without seeing target header files?  We
> are talking about a native build, not a cross build.

Eli, is it a big difference for us, does GCC get definition from djgpp
header, or from GCC target description one with Mark's patch?

+ #undef SIZE_TYPE
+ #define SIZE_TYPE "long unsigned int"
[and so on]

> And yes, we did read all the threads in GCC archives that appear to be
> relevant, and we did discuss them at length.  But we still do not
> understand the technical considerations that caused GCC to insist on
> installing its own headers.  Please help us understand this.

Uhm, how would you qualify following response:
> Wrong. GCC needs to know exactly what size_t and wchar_t is, and it
> must also provide the definition of NULL. size_t must be known so the
> builtin functions can be declared properly. wchar_t must be known so
> wide string literals can be emitted correctly. NULL is defined as
> __null on all platforms now, so that overloading works correctly in
> C++ (for C, it is something different).

Laurynas

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Mon, 17 Jul 2000 14:28:17 -0700 (PDT)
> 
> Simple, gcc knows the target system, including details that affect
> these things.  Does it mean that gcc has to know a bit about target
> system, sure.

GCC should have no problems knowing a bit about a target system: it
just needs to include the system headers for that.  It's all there.

> Understand why we #define it to __null and you'll gain a better
> understanding of the varargs.

This is *exactly* the point: no matter how much we read and re-read
the relevant discussions in GCC archives, we could _not_ understand
why there's a need for __null in C programs.  That's why Laurynas
wrote his message in the first place: we are asking to help us
understand the technical issues behind this, so we could suggest
plausible solutions.

> But.h, is another good example.  Ours works, it'll always work, we
> prefer it, why not use it?  Is your version safe with
> -fstrict-aliasing?  Are you sure?  By using ours, we know ours is.

Are you sure your version doesn't break the library?  I don't think
you can be sure of that, unless you really studied the internals of
that particular library.

IMHO, it is the business of library maintainers to make sure their
definitions work correctly.  While suggesting to use GCC's definitions
is nice, they should not be _forced_ on the library, because there's a
slight chance that the library maintainers can indeed get it right on
their own.

In other words, the possibility that system headers might not work
right is IMHO not a valid technical reason to force a library to use
different definitions.  GCC should simply assume that the system
headers work, and if they don't, tell the maintainers to get them
right.  At least with libraries that are Free Software this should
work.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Mon, 17 Jul 2000 23:02:50 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> 
> GCC needs to know exactly what size_t and wchar_t is

This knowledge is accessible to GCC at build time, in the system
headers.

> NULL is defined as __null on all platforms now

Not in DJGPP.  __null causes trouble in C programs.

> there is no question *that* gcc must know about
> these types even without seeing a single target header file.

Why does it need to know that without seeing target header files?  We
are talking about a native build, not a cross build.

The issue that started this thread is that the DJGPP maintainers don't
understand the _technical_ reasons why should there be any need for
GCC to insist on its own, possibly incompatible, definitions.  That is
what we are asking to explain.  It is most probable that, once we
understand the technical issues involved, a number of plausible
solutions could be suggested.

And yes, we did read all the threads in GCC archives that appear to be
relevant, and we did discuss them at length.  But we still do not
understand the technical considerations that caused GCC to insist on
installing its own headers.  Please help us understand this.

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> Date: Mon, 17 Jul 2000 11:49:36 -0700
> From: Bruce Korb <bkorb@sco.COM>
> 
> However, I would work with anyone among the
> djgpp-workers interested in making the fixincl program run
> under Win*.  :-)

The problem is that we (the DJGPP maintainers) don't understand why
should the headers need to be ``fixed''.  As far as we know, they are
just fine.

Re: GCC headers and DJGPP port

[Bruce Korb]

"Mark E." wrote:
> 
> > The "how" of this question is the port maintainer figures out the right
> > value and codes it into the target .h file.  For example:
> 
> Thanks for the info. Looking at the gcc source, the defaults already work
> fine, but since defaults can change so it's probably not a good idea to rely
> on it. I'll revise my current DJGPP config patch to include these
> definitions.

fixincludes really has the same issue.  It is really quite obtuse
as to how I can pull:

  #define PTRDIFF_TYPE "int"

out of, say, gcc/config/i386/linux.h.  It would be nice to make
the ptrdiff_t, size_t and wchar_t hacks based on some well-known
file like "deduced.h".  Unfortunately, these are not useful:

  #define ptrdiff_t __PTRDIFF_TYPE__
  #define size_t __SIZE_TYPE__

I guess my questions are, "Do the config/*/*.h files get mapped
or copied into a well-known name?  How can I use them?"

:-)

Thanks!

Re: GCC headers and DJGPP port

[Mark E.]

> The "how" of this question is the port maintainer figures out the right
> value and codes it into the target .h file.  For example:

Thanks for the info. Looking at the gcc source, the defaults already work 
fine, but since defaults can change so it's probably not a good idea to rely 
on it. I'll revise my current DJGPP config patch to include these 
definitions.

Mark

Re: GCC headers and DJGPP port

[Jeffrey A Law]

  In message < 200007172102.XAA07817@loewis.home.cs.tu-berlin.de >you write:
  > Now, the exact mechanism *how* it is achieved that the header file is
  > an exact match of the target understanding of these types is a tricky
  > question, however, there is no question *that* gcc must know about
  > these types even without seeing a single target header file.
The "how" of this question is the port maintainer figures out the right
value and codes it into the target .h file.  For example:

/* Make GCC agree with types.h.  */
#undef SIZE_TYPE
#undef PTRDIFF_TYPE

#define SIZE_TYPE "long unsigned int"
#define PTRDIFF_TYPE "long int"

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Mon, 17 Jul 2000 14:34:27 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: Mike Stump <mrs@windriver.com>

> > From: Mike Stump <mrs@windriver.com>
> > Date: Mon, 17 Jul 2000 10:36:53 -0700 (PDT)
> > 
> Sorry, I don't understand how can this ever work reliably.

Simple, gcc knows the target system, including details that affect
these things.  Does it mean that gcc has to know a bit about target
system, sure.  Welcome to gcc.

> I don't see how can GCC provide definitions that will never conflict
> with library internals.  Please tell what am I missing.

> How about a system with its own stddef.h?  Standard types such as
> the definition of NULL -- these are surely closely related to the
> internals of a library, right?

:-) Actually, this is the canonical example for of one that we prefer
our definition for.  Understand why we #define it to __null and you'll
gain a better understanding of the issues.

varargs.h, is another good example.  Ours works, it'll always work, we
prefer it, why not use it?  Is your version safe with
-fstrict-aliasing?  Are you sure?  By using ours, we know ours is.

Re: GCC headers and DJGPP port

[Martin v. Loewis]

> How about a system with its own stddef.h?  Standard types such as
> size_t, wchar_t, the definition of NULL -- these are surely closely
> related to the internals of a library, right?  And GCC has no means
> of knowing how to define these correctly for the library, right?

Wrong. GCC needs to know exactly what size_t and wchar_t is, and it
must also provide the definition of NULL. size_t must be known so the
builtin functions can be declared properly. wchar_t must be known so
wide string literals can be emitted correctly. NULL is defined as
__null on all platforms now, so that overloading works correctly in
C++ (for C, it is something different).

Now, the exact mechanism *how* it is achieved that the header file is
an exact match of the target understanding of these types is a tricky
question, however, there is no question *that* gcc must know about
these types even without seeing a single target header file.

Regards,
Martin

Re: GCC headers and DJGPP port

[Bruce Korb]

DJ Delorie wrote:
> 
> > Suppose the GCC-supplied "stddef.h" were to do stuff like:
> > ...
> > and the DJGPP headers were to do the same?  :-)
> 
> If you can guarantee that gcc won't change it's mind *again* I suppose
> we could agree on something like this.

The fixincludes hackery that uses this mechanism dates from the
shell script I used as the basis for the new, improved fixincludes.
I won't be changing it.

> Unfortunately, DJGPP is a *dos* program, not a Win32 program.  That
> makes things even harder (but not impossible).  We have popen()
> and system(), but not fork().

Then it would seem possible that the "process()" fixincl routine
could be reworked for DOS such that the fork(2) calls get
replaced with system(3) calls, a la:

   sprintf( buf,
   "src=%s ; dest=%s ; fix=%s\n"
   "fixincfix $fix $src FIXINC.TMP\n"
   "mv -f FIXINC.TMP $dest", pz_src, pz_dest, pz_fix_name );
   system( buf );

(modified as required for the DOS environment).
I think the shell server could be disposed of with a little
effort.  It is not widely used inside of fixincl anymore.
Obviously, the "fixincfixer" program would have to be
resurrected.  That would not be too hard.

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Bruce Korb wrote:
> Suppose the GCC-supplied "stddef.h" were to do stuff like:
> 
> > #ifndef __PTRDIFF_TYPE__
> > #define __PTRDIFF_TYPE__ long int
> > #endif
> > #if !defined(_GCC_PTRDIFF_T)
> > #define _GCC_PTRDIFF_T
> > typedef __PTRDIFF_TYPE__ ptrdiff_t;
> > #endif

[etcetera...]

> and the DJGPP headers were to do the same?  :-)

Yes, it is possible. But the main technical objection (not counting
political ones) is that users will have to upgrade DJGPP libc if they
want GCC 3.0. And, if I understand correctly, one of the reasons to provide
GCC headers was ability _not_ to upgrade libc for new GCC. A little bit
different goals. But this solution is possible and will be considered
if nothing better comes up.

> And because the main shell script version has been removed,
> I pulled the support for doing c-fixes from a command line.
> But I thought you-all used "fixinc.winnt" anyway?  

No, we just disabled fixincludes. Maybe CygWin or MingW used that.

> Since I
> don't have a Windows dev box, I was never planning on touching
> that mechanism.  However, I would work with anyone among the
> djgpp-workers interested in making the fixincl program run
> under Win*.  :-)

[You mean DOS, not Win*, right?]

Why not? ;-) I'll be glad to help in future (I'm pretty busy at the
moment)

Laurynas

Re: GCC headers and DJGPP port

[DJ Delorie]

> Suppose the GCC-supplied "stddef.h" were to do stuff like:
> ...
> and the DJGPP headers were to do the same?  :-)

If you can guarantee that gcc won't change it's mind *again* I suppose
we could agree on something like this.  Historically, though, I've had
to tweak headers with each gcc release whether I "played by the rules"
or did my own thing.  For a long time, it seemed that gcc was going to
be a moving target no matter what I tried, so I went with the simplest
solution for me.

> But I thought you-all used "fixinc.winnt" anyway?  Since I
> don't have a Windows dev box, I was never planning on touching
> that mechanism.  However, I would work with anyone among the
> djgpp-workers interested in making the fixincl program run
> under Win*.  :-)

Unfortunately, DJGPP is a *dos* program, not a Win32 program.  That
makes things even harder (but not impossible).  We have popen()
and system(), but not fork().

Re: GCC headers and DJGPP port

[Mark E.]

> Mike Stump wrote:
> > A sure sign of a non-maintained port, is a system with its own
> > vararg.h...
> 
> Or is it a sign of system which had its own little GCC fork previously?

Which we're actively trying to eliminate now. But when patches to close this 
gap go undealt with while others are quickly handled, it is tempting to think 
the maintainers aren't inclined to help eliminate the gap. 

Mark

Re: GCC headers and DJGPP port

[Bruce Korb]

Laurynas Biveinis, et al. wrote:  <<stuff>>

> Suppose we put following in GCC headers
> 
> #ifdef __DJGPP__
> #include <sys/djtypes.h>
> #undef __DJ_size_t
> #define __DJ_size_t
> /* ... normal size_t definition as usual ... */
> 
> This way we get GCC size_t definition and DJGPP headers won't redefine it.
> But everything will be OK only as long as GCC headers come first. Just do
> #include <go32.h>
> #include <stddef.h>
> and we are in trouble - GCC header is unable to detect that size_t is 
> already defined.

Suppose the GCC-supplied "stddef.h" were to do stuff like:

> #ifndef __PTRDIFF_TYPE__
> #define __PTRDIFF_TYPE__ long int
> #endif
> #if !defined(_GCC_PTRDIFF_T)
> #define _GCC_PTRDIFF_T
> typedef __PTRDIFF_TYPE__ ptrdiff_t;
> #endif
> 
> #ifndef __SIZE_TYPE__
> #define __SIZE_TYPE__ long unsigned int
> #endif
> #if !defined(_GCC_SIZE_T)
> #define _GCC_SIZE_T
> typedef __SIZE_TYPE__ size_t;
> #endif
>
> #ifndef __WCHAR_TYPE__
> #define __WCHAR_TYPE__ int
> #endif
> #if !defined(_GCC_WCHAR_T) && !defined(__cplusplus)
> #define _GCC_WCHAR_T
> typedef __WCHAR_TYPE__ wchar_t;
> #endif

and the DJGPP headers were to do the same?  :-)

> > If your header files are defining things in the wrong way in the wrong
> > places, then fixincludes is your solution.
> 
> Fixincludes won't run on DJGPP in near future - we don't have pipe(), fork(),
> etc. stuff. And shell script version has been removed.

And because the main shell script version has been removed,
I pulled the support for doing c-fixes from a command line.
But I thought you-all used "fixinc.winnt" anyway?  Since I
don't have a Windows dev box, I was never planning on touching
that mechanism.  However, I would work with anyone among the
djgpp-workers interested in making the fixincl program run
under Win*.  :-)

Re: GCC headers and DJGPP port

[Eli Zaretskii]

> From: Mike Stump <mrs@windriver.com>
> Date: Mon, 17 Jul 2000 10:36:53 -0700 (PDT)
> 
> Let it install and use its own headers, remove your headers, and fix
> the port, if any of the bits are wrong.

Sorry, I don't understand how can this ever work reliably.  Some of
the definitions provided by the headers that GCC wants to install are
closely related to the library.  I don't see how can GCC provide
definitions that will never conflict with library internals.  Please
tell what am I missing.

> A sure sign of a non-maintained port, is a system with its own
> vararg.h...

How about a system with its own stddef.h?  Standard types such as
size_t, wchar_t, the definition of NULL -- these are surely closely
related to the internals of a library, right?  And GCC has no means of
knowing how to define these correctly for the library, right?

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Mike Stump wrote:
> A sure sign of a non-maintained port, is a system with its own
> vararg.h...

Or is it a sign of system which had its own little GCC fork previously?

Laurynas

Re: GCC headers and DJGPP port

[Mike Stump]

> Date: Sun, 16 Jul 2000 16:42:50 +0200
> From: Laurynas Biveinis <lauras@softhome.net>
> To: gcc@gcc.gnu.org

> One of the major problems requiring addressing is relationship between
> following DJGPP and GCC-provided headers: stddef.h, stdarg.h and
> varargs.h. The problem is that GCC wants to use and install its
> own headers, but it causes type redefinitions, e.g.:

> How would you suggest to fix it?

Let it install and use its own headers, remove your headers, and fix
the port, if any of the bits are wrong.

A sure sign of a non-maintained port, is a system with its own
vararg.h...

Re: GCC headers and DJGPP port

[Laurynas Biveinis]

Jeffrey A Law wrote:
> Well, I wouldn't expect it to be significantly different than how this
> is handled on other platforms.

There are differences between DJGPP and other platforms in how we 
avoid type redefinitions in our headers.

Suppose we put following in GCC headers

#ifdef __DJGPP__
#include <sys/djtypes.h>
#undef __DJ_size_t
#define __DJ_size_t
/* ... normal size_t definition as usual ... */

This way we get GCC size_t definition and DJGPP headers won't redefine it.
But everything will be OK only as long as GCC headers come first. Just do
#include <go32.h>
#include <stddef.h>
and we are in trouble - GCC header is unable to detect that size_t is 
already defined.

We could fix that by 

#ifdef __DJGPP__
#include <sys/djtypes.h>
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
#else
/* ... normal size_t definition as usual ... */
#endif

The difference is that GCC header will get and use size_t from DJGPP
instead of defining its own. Is it OK with you?

> If your header files are defining things in the wrong way in the wrong
> places, then fixincludes is your solution.

Fixincludes won't run on DJGPP in near future - we don't have pipe(), fork(),
etc. stuff. And shell script version has been removed.

Laurynas

Re: GCC headers and DJGPP port

[Jeffrey A Law]

  In message < 3971C9EA.C2643725@softhome.net >you write:
  > For the upcoming GCC 3.0 release, DJGPP team has decided to make GCC
  > build out-of-box.
That would be nice.

  > One of the major problems requiring addressing is relationship between
  > following DJGPP and GCC-provided headers: stddef.h, stdarg.h and
  > varargs.h. The problem is that GCC wants to use and install its
  > own headers, but it causes type redefinitions, e.g.:

  > ---
  > In file included from ../../gcc/tsystem.h:52,
  >                  from ../../gcc/libgcc2.c:37:
  > d:/djgpp/include/stdio.h:35: warning: redefinition of `va_list'
  > include/stdarg.h:110: warning: `va_list' previously declared here
  > d:/djgpp/include/stdio.h:38: warning: redefinition of `size_t'
  > include/stddef.h:199: warning: `size_t' previously declared here
  > In file included from ../../gcc/tsystem.h:69,
  >                  from ../../gcc/libgcc2.c:37:
  > d:/djgpp/include/stdlib.h:39: warning: redefinition of `wchar_t'
  > include/stddef.h:287: warning: `wchar_t' previously declared here
  > ---
  > How would you suggest to fix it?
Well, I wouldn't expect it to be significantly different than how this
is handled on other platforms.


  > Currently we see following possible solutions:
  > 1) Override USER_H and not install those headers for DJGPP.
  > However, discussion between FreeBSD maintainers and you showed
  > that you're not going to accept this solution, although we
  > were unable to find any _technical_ arguments for doing so.
  > Previously GCC on DJGPP has always worked without installing
  > its own headers and that's the preferred solution for us,
  > unless there are serious objections.
There are technical arguments in the archives.  THe basic and fundamental
problem is gcc is designed to work with its headers which implement
stuff like varargs or various C++ thingies.

Overriding USER_H causes some subset of GCC's header files to not be
installed.  I've yet to see a case where that's actually the right
thing to do (and I'm the person that actually came up with the USER_H
override to begin with).

If your header files are defining things in the wrong way in the wrong
places, then fixincludes is your solution.

I would recommend looking into how other systems avoid redefinitions of
size_t and friends and do similar things.

jeff

GCC headers and DJGPP port

[Laurynas Biveinis]

For the upcoming GCC 3.0 release, DJGPP team has decided to make GCC
build out-of-box. Of course, GCC has been ported there for a long
time. However, the port was not clean due to many reasons - missing
UNIXish features, ports of bash and other programs. Most of those
problems were addressed, but few porting issues still exist. We
would appreciate any help there.

One of the major problems requiring addressing is relationship between
following DJGPP and GCC-provided headers: stddef.h, stdarg.h and
varargs.h. The problem is that GCC wants to use and install its
own headers, but it causes type redefinitions, e.g.:
---
In file included from ../../gcc/tsystem.h:52,
                 from ../../gcc/libgcc2.c:37:
d:/djgpp/include/stdio.h:35: warning: redefinition of `va_list'
include/stdarg.h:110: warning: `va_list' previously declared here
d:/djgpp/include/stdio.h:38: warning: redefinition of `size_t'
include/stddef.h:199: warning: `size_t' previously declared here
In file included from ../../gcc/tsystem.h:69,
                 from ../../gcc/libgcc2.c:37:
d:/djgpp/include/stdlib.h:39: warning: redefinition of `wchar_t'
include/stddef.h:287: warning: `wchar_t' previously declared here
---
How would you suggest to fix it?
Currently we see following possible solutions:
1) Override USER_H and not install those headers for DJGPP.
However, discussion between FreeBSD maintainers and you showed
that you're not going to accept this solution, although we
were unable to find any _technical_ arguments for doing so.
Previously GCC on DJGPP has always worked without installing
its own headers and that's the preferred solution for us,
unless there are serious objections.

This means that either ours, either yours (or both) headers
should be changed, the question - which ones and how?
Right now we have one internal header which defines macros
which define types, like:
#define __DJ_size_t typedef long unsigned int size_t;
Now in our headers which need size_t we do:
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
This way we prevent multiple redefinitions.

So we could:
2) Add that stuff to GCC headers:
#ifdef __DJGPP__
#include <sys/djtypes.h>
__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
#else
typedef ...
#endif
This trick would get DJGPP definitions and this solution is OK
with us, but is it OK with you? It means that DJGPP and your
definitions may differ and this is not good if you wanted to
have common definitions for all systems.

3) The last possible solution is adjusting our headers. While we
admit that our headers are not 100%-ANSI compatible (e.g. stdio.h
defines va_list), it would break backwards compatibility and would 
require DJGPP users to upgrade if they want later GCC version (If 
I understand correctly, one of the arguments for installing your 
headers is that user should not have to update library if he wants 
newer GCC? But in this case it would cause the opposite).
This solution is the worst from the end-user's point of view and
we see it as last resort.

What are your opinions and suggestions?
Thanks in advance,
DJGPP team