Re: FreeBSD 4.0

Re: FreeBSD 4.0

[Mike Stump]

We have seen this same issue a couple of times.  HJ wanted to put
--prefix=/usr in the compiler for linux systems, we told him to take a
leap.  It is wrong, plain wrong.  Only two people in the world should
do that, the end user that wants to clobber his system, or that
distribution manager for /usr.

You are in the exact same case.  You want to put things that are only
relevant to your one build, but screw all the other folks in the world.

gcc doesn't cater to people like you.  It caters to all the other
folks that want to install a new compiler in a non-conflicting way on
their system.

Once you readjust your philosophy around to match the gcc philosophy,
you will see why what law says is true.


> Date: Thu, 16 Sep 1999 16:41:15 +0200
> From: Marc Espie <espie@quatramaran.ens.fr>

> I concur that, if the end user want to fiddle with a newer gcc snapshot,
> USER_H is in the way.

See, this is wrong.  Use the phrase, if the end user wants to fiddle
with a newer gcc snapshot, everything will always just work.  If the
distribution packager wants to build up a distribution, they will have
to fiddle with USER_H...

It would be nice if the internal documentation covered this some...

It would be nice if --enable-distributorbuild or somesuch could make
your life easier.  Then we serve all folks (good in this case I
think).  Then HJ could put the defaulting of prefix to /usr back in.

Re: FreeBSD 4.0

[Marc Espie]

In article < 199909162013.NAA10276@kankakee.wrs.com > you write:
>You are in the exact same case.  You want to put things that are only
>relevant to your one build, but screw all the other folks in the world.

I don't want to screw anybody else.
I want to make sure stuff works, possibly both ways.

>gcc doesn't cater to people like you.  It caters to all the other
>folks that want to install a new compiler in a non-conflicting way on
>their system.
>
>Once you readjust your philosophy around to match the gcc philosophy,
>you will see why what law says is true.
>
>
>> Date: Thu, 16 Sep 1999 16:41:15 +0200
>> From: Marc Espie <espie@quatramaran.ens.fr>
>
>> I concur that, if the end user want to fiddle with a newer gcc snapshot,
>> USER_H is in the way.
>
>See, this is wrong.  Use the phrase, if the end user wants to fiddle
>with a newer gcc snapshot, everything will always just work.  If the
>distribution packager wants to build up a distribution, they will have
>to fiddle with USER_H...

Sigh. I wonder if I speak martian of something sometimes...
See, this is exactly what I mean.
I do understand that the end user  may want to install a newer compiler
on an older OpenBSD.  I have absolutely no problem with this.
*of course* he shouldn't get fucked by whatever we want to do with the
compiler.

In fact, one point of my getting involved with gcc was to make sure
what we had in tree matches *precisely* the current development tree,
apart from a few, well-documented patches *and* making the patches 
available, so that Joe User gets a choice.

What I mean is that we want to keep upgrading our system headers.
We want them to work, we want the current system to match what gcc
needs.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909162035.WAA19219@quatramaran.ens.fr >you write:
  > Sigh. I wonder if I speak martian of something sometimes...
  > See, this is exactly what I mean.
  > I do understand that the end user  may want to install a newer compiler
  > on an older OpenBSD.  I have absolutely no problem with this.
  > *of course* he shouldn't get fucked by whatever we want to do with the
  > compiler.
You and MRS are both wrong in this case.  You still do not want to override
USER_H, even if you "own" /usr as the distribution maintainer.

And you'll find that if you do things the right way from the start that
you won't need to override USER_H, even when building your distributions.


  > What I mean is that we want to keep upgrading our system headers.
  > We want them to work, we want the current system to match what gcc
  > needs.
And that's fine.  I did it myself in the pre-net2 days for Berkeley.  To find
out what's getting mashed you install the compiler, then go look at what's
in its include directory.  Manually filter out the small number of files it's
going to always install (which you absolutely should not override).

jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909162035.WAA19219@quatramaran.ens.fr >you write:
  > Sigh. I wonder if I speak martian of something sometimes...
  > See, this is exactly what I mean.
  > I do understand that the end user  may want to install a newer compiler
  > on an older OpenBSD.  I have absolutely no problem with this.
  > *of course* he shouldn't get fucked by whatever we want to do with the
  > compiler.
You and MRS are both wrong in this case.  You still do not want to override
USER_H, even if you "own" /usr as the distribution maintainer.

And you'll find that if you do things the right way from the start that
you won't need to override USER_H, even when building your distributions.


  > What I mean is that we want to keep upgrading our system headers.
  > We want them to work, we want the current system to match what gcc
  > needs.
And that's fine.  I did it myself in the pre-net2 days for Berkeley.  To find
out what's getting mashed you install the compiler, then go look at what's
in its include directory.  Manually filter out the small number of files it's
going to always install (which you absolutely should not override).

jeff

Re: FreeBSD 4.0

[Marc Espie]

In article < 199909162013.NAA10276@kankakee.wrs.com > you write:
>You are in the exact same case.  You want to put things that are only
>relevant to your one build, but screw all the other folks in the world.

I don't want to screw anybody else.
I want to make sure stuff works, possibly both ways.

>gcc doesn't cater to people like you.  It caters to all the other
>folks that want to install a new compiler in a non-conflicting way on
>their system.
>
>Once you readjust your philosophy around to match the gcc philosophy,
>you will see why what law says is true.
>
>
>> Date: Thu, 16 Sep 1999 16:41:15 +0200
>> From: Marc Espie <espie@quatramaran.ens.fr>
>
>> I concur that, if the end user want to fiddle with a newer gcc snapshot,
>> USER_H is in the way.
>
>See, this is wrong.  Use the phrase, if the end user wants to fiddle
>with a newer gcc snapshot, everything will always just work.  If the
>distribution packager wants to build up a distribution, they will have
>to fiddle with USER_H...

Sigh. I wonder if I speak martian of something sometimes...
See, this is exactly what I mean.
I do understand that the end user  may want to install a newer compiler
on an older OpenBSD.  I have absolutely no problem with this.
*of course* he shouldn't get fucked by whatever we want to do with the
compiler.

In fact, one point of my getting involved with gcc was to make sure
what we had in tree matches *precisely* the current development tree,
apart from a few, well-documented patches *and* making the patches 
available, so that Joe User gets a choice.

What I mean is that we want to keep upgrading our system headers.
We want them to work, we want the current system to match what gcc
needs.

Re: FreeBSD 4.0

[Mike Stump]

We have seen this same issue a couple of times.  HJ wanted to put
--prefix=/usr in the compiler for linux systems, we told him to take a
leap.  It is wrong, plain wrong.  Only two people in the world should
do that, the end user that wants to clobber his system, or that
distribution manager for /usr.

You are in the exact same case.  You want to put things that are only
relevant to your one build, but screw all the other folks in the world.

gcc doesn't cater to people like you.  It caters to all the other
folks that want to install a new compiler in a non-conflicting way on
their system.

Once you readjust your philosophy around to match the gcc philosophy,
you will see why what law says is true.


> Date: Thu, 16 Sep 1999 16:41:15 +0200
> From: Marc Espie <espie@quatramaran.ens.fr>

> I concur that, if the end user want to fiddle with a newer gcc snapshot,
> USER_H is in the way.

See, this is wrong.  Use the phrase, if the end user wants to fiddle
with a newer gcc snapshot, everything will always just work.  If the
distribution packager wants to build up a distribution, they will have
to fiddle with USER_H...

It would be nice if the internal documentation covered this some...

It would be nice if --enable-distributorbuild or somesuch could make
your life easier.  Then we serve all folks (good in this case I
think).  Then HJ could put the defaulting of prefix to /usr back in.

Re: FreeBSD 4.0

[Mike Stump]

> Date: Mon, 20 Sep 1999 18:33:58 +0100
> From: Richard Earnshaw <rearnsha@arm.com>

> But what if I want to pass my code through lint?

There is no restriction against using lint.  What did you want to do?
The only think that _might_ at all be contentious is distributing lint
libraries derived from those headers.  I think our intent is to allow
this on the grounds that it isn't copyrightable.  It would be nice if
there was wording somewhere that somehow gace permission.  Other tools
I think should be included (TAGS files, source code search databases)
as well as lint.

Re: FreeBSD 4.0

[Mike Stump]

> Date: Mon, 20 Sep 1999 18:33:58 +0100
> From: Richard Earnshaw <rearnsha@arm.com>

> But what if I want to pass my code through lint?

There is no restriction against using lint.  What did you want to do?
The only think that _might_ at all be contentious is distributing lint
libraries derived from those headers.  I think our intent is to allow
this on the grounds that it isn't copyrightable.  It would be nice if
there was wording somewhere that somehow gace permission.  Other tools
I think should be included (TAGS files, source code search databases)
as well as lint.

Re: FreeBSD 4.0

[Mike Stump]

> Date: Thu, 16 Sep 1999 10:46:15 +0200
> From: Marc Espie <espie@quatramaran.ens.fr>

> As far as OpenBSD goes, we are willing to fix our header files over time.

I am sorry, but you can only do this for half of the cases.  The other
half imply time travel.  Or put another way, fixing an old OS to
conform to the wants of a new compiler, is hard.

> We can provide header archives to install with the compiler, if updates
> are needed.

Yes, this is closer, but bear in mind that gcc doesn't _want_ to tote
around every header for every OS.  Instead it totes around fixincludes
that can `generate on the fly' every header for every OS.

And we are now right back where we started.

Re: FreeBSD 4.0

[Mike Stump]

> Date: Thu, 16 Sep 1999 10:46:15 +0200
> From: Marc Espie <espie@quatramaran.ens.fr>

> As far as OpenBSD goes, we are willing to fix our header files over time.

I am sorry, but you can only do this for half of the cases.  The other
half imply time travel.  Or put another way, fixing an old OS to
conform to the wants of a new compiler, is hard.

> We can provide header archives to install with the compiler, if updates
> are needed.

Yes, this is closer, but bear in mind that gcc doesn't _want_ to tote
around every header for every OS.  Instead it totes around fixincludes
that can `generate on the fly' every header for every OS.

And we are now right back where we started.

FreeBSD 4.0

[Wes Morgan]

Trying to build the latest CVS snapshot under freebsd 4.0 fails with these
errors:

In file included from ../../egcs/gcc/libgcc2.c:1408:
include/stdio.h:245: parse error before `__gnuc_va_list'
include/stdio.h:246: parse error before `__gnuc_va_list'
include/stdio.h:247: parse error before `__gnuc_va_list'
include/stdio.h:311: parse error before `__gnuc_va_list'
include/stdio.h:313: parse error before `__gnuc_va_list'
include/stdio.h:315: parse error before `__gnuc_va_list'
include/stdio.h:316: parse error before `__gnuc_va_list'
include/stdio.h:346: parse error before `__gnuc_va_list'
*** Error code 1


There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some
of the changelogs, but I haven't seen anything conclusive... Is this a
known problem, or is my CVS tree out of sync somehow? Or maybe I need to
set some different CFLAGS?

WM

-- 
The difference between genius and stupidity is that genius has its limits.
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: FreeBSD 4.0

[Richard Henderson]

On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote:
> In file included from ../../egcs/gcc/libgcc2.c:1408:
> include/stdio.h:245: parse error before `__gnuc_va_list'

I just checked in a much simplified version of stdarg.h.
Would you send me a preprocessed copy and we can figure
out what went wrong.


r~

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990914200826.A7982@cygnus.com >you write:
  > On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote:
  > > In file included from ../../egcs/gcc/libgcc2.c:1408:
  > > include/stdio.h:245: parse error before `__gnuc_va_list'
  > 
  > I just checked in a much simplified version of stdarg.h.
  > Would you send me a preprocessed copy and we can figure
  > out what went wrong.
  > 
I believe this problem pre-dates the va-* reorg.  We've got to get the stddef.h
and fixinc stuff for freebsd re-reviewed and deal with the remaining issues.

jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990914200826.A7982@cygnus.com >you write:
  > On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote:
  > > In file included from ../../egcs/gcc/libgcc2.c:1408:
  > > include/stdio.h:245: parse error before `__gnuc_va_list'
  > 
  > I just checked in a much simplified version of stdarg.h.
  > Would you send me a preprocessed copy and we can figure
  > out what went wrong.
  > 
I believe this problem pre-dates the va-* reorg.  We've got to get the stddef.h
and fixinc stuff for freebsd re-reviewed and deal with the remaining issues.

jeff

Re: FreeBSD 4.0

[Richard Henderson]

On Tue, Sep 14, 1999 at 10:33:00PM -0400, Wes Morgan wrote:
> In file included from ../../egcs/gcc/libgcc2.c:1408:
> include/stdio.h:245: parse error before `__gnuc_va_list'

I just checked in a much simplified version of stdarg.h.
Would you send me a preprocessed copy and we can figure
out what went wrong.


r~

Re: FreeBSD 4.0

[Loren James Rittle]

Wes Morgan wrote:

> Trying to build the latest CVS snapshot under freebsd 4.0 fails with these
> errors:

...
> include/stdio.h:245: parse error before `__gnuc_va_list'
...

> There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some
> of the changelogs, but I haven't seen anything conclusive... Is this a
> known problem, or is my CVS tree out of sync somehow? Or maybe I need to
> set some different CFLAGS?

I have built gcc_ss_19990913 on FreeBSD 3.2-RELEASE with the patches
in http://egcs.cygnus.com/ml/gcc-patches/1999-08/msg00728.html (they
have been *REQUIRED* on FreeBSD for some time).  The issue is that
ports may no longer override USER_T in order to keep fixinc from running.

Richard Henderson wrote:

> I just checked in a much simplified version of stdarg.h.
> Would you send me a preprocessed copy and we can figure
> out what went wrong.

Cool!  If you have upgraded past gcc_ss_19990913 and picked up
Richard's latest changes, then I can now confirm (since I just
finished a bootstrap on the mainline with his changes) that the
gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer
needed (since he removed the code that those patches affected ;-)!

Unfortunately (although extremely minor), that means that until I get
around to investigating the root issue in fixinc, any C++ code that
relies on system headers which use _BSD_VA_LIST_ instead of va_list
(not including stdio.h which is now correctly fixed) will fail with
errors of this form:

cannot convert `void *' to `char *' for argument `X' to `foo(...)'

Richard, is it your position that all system headers must be fixed to
only reference __gnuc_va_list instead of va_list and/or
system-specific macros such as _BSD_VA_LIST_ (as was historically used
by BSD systems)?  If so, then fixinc's rule to mung _BSD_VA_LIST_ into
__gnuc_va_list must be expanded to operate on 10-15 other standard BSD
system headers...

Wes, if you could tell me if the referenced patches work for you under
FreeBSD 4.0, that could be helpful.

Regards,
Loren

Re: FreeBSD 4.0

[Zack Weinberg]

Loren James Rittle wrote:
> 
> Unfortunately (although extremely minor), that means that until I get
> around to investigating the root issue in fixinc, any C++ code that
> relies on system headers which use _BSD_VA_LIST_ instead of va_list
> (not including stdio.h which is now correctly fixed) will fail with
> errors of this form:
> 
> cannot convert `void *' to `char *' for argument `X' to `foo(...)'
> 
> Richard, is it your position that all system headers must be fixed to
> only reference __gnuc_va_list instead of va_list and/or
> system-specific macros such as _BSD_VA_LIST_ (as was historically used
> by BSD systems)?  If so, then fixinc's rule to mung _BSD_VA_LIST_ into
> __gnuc_va_list must be expanded to operate on 10-15 other standard BSD
> system headers...

May I suggest that stdarg.h/varargs.h be modified to #define
_BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
limit it to FreeBSD?  (Is this needed by Net/OpenBSD too?)  This is
simpler and less fragile than adding stuff to fixinc.

For complicated reasons related to similar interactions with glibc's
headers, I'd personally like to see the typedef name be __va_list, and
__gnuc_va_list a #define as well.

zw

Re: FreeBSD 4.0

[David O'Brien]

> May I suggest that stdarg.h/varargs.h be modified to #define
> _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
> limit it to FreeBSD?  

Why not do it the other way around?

    #define __gnuc_va_list _BSD_VA_LIST_

Please, please lets not require the dinking of many system headers.
Please also remember GCC is the base compiler in BSD and the number of
things that have to be changed when native'ifing the compiler the better.


> (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
> than adding stuff to fixinc.

This is a 4.4BSD thing.  It thus affects all of BSD.

 
> For complicated reasons related to similar interactions with glibc's
> headers, I'd personally like to see the typedef name be __va_list, and
> __gnuc_va_list a #define as well.

Can you explain these interactions?  I really doubt the BSD headers are
as intertwined.

Re: FreeBSD 4.0

[Zack Weinberg]

"David O'Brien" wrote:
> > May I suggest that stdarg.h/varargs.h be modified to #define
> > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
> > limit it to FreeBSD?  
> 
> Why not do it the other way around?
> 
>     #define __gnuc_va_list _BSD_VA_LIST_

Because the "real" type is __gnuc_va_list.  Doing it your way won't do
what you want.  I hope you don't have system headers that typedef
_BSD_VA_LIST_ without reference to gcc's stdarg.h - for one thing, we
probably just irrevocably broke them.

> Please, please lets not require the dinking of many system headers.
> Please also remember GCC is the base compiler in BSD and the number of
> things that have to be changed when native'ifing the compiler the better.

I believe #define _BSD_VA_LIST_ __gnuc_va_list will solve your problem
without any dinking of BSD libc headers.

> > (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
> > than adding stuff to fixinc.
> 
> This is a 4.4BSD thing.  It thus affects all of BSD.

Is there any macro which is defined by all 4.4-derived systems?

> > For complicated reasons related to similar interactions with glibc's
> > headers, I'd personally like to see the typedef name be __va_list, and
> > __gnuc_va_list a #define as well.
> 
> Can you explain these interactions?  I really doubt the BSD headers are
> as intertwined.

The intertwining with glibc is not as bad as you might think, and
__gnuc_va_list is actually the least bad part.  For real issues, try
to figure out what wint_t is doing in stddef.h, or how limits.h works.

The problem with __gnuc_va_list is primarily aesthetic.  Everyone has
to agree on the underlying typedef name because of C++ mangled names.
Therefore I would like the underlying typedef name to be
compiler-neutral.  People do want to use glibc with compilers other
than gcc.

zw

Re: FreeBSD 4.0

[David O'Brien]

> Is there any macro which is defined by all 4.4-derived systems?

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif

   to detect if the code is being compiled on a 4.3 Net2 code base or
   newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and
   below).

#if (defined(BSD) && (BSD >= 199103))

   to detect if the code is being compiled on a 4.4 code base or newer
   (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above).

#if (defined(BSD) && (BSD >= 199306))

Re: FreeBSD 4.0

[Andreas Schwab]

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

"David O'Brien" <obrien@NUXI.com> writes:

|> > Is there any macro which is defined by all 4.4-derived systems?
|> 
|> #if (defined(__unix__) || defined(unix)) && !defined(USG)
                                     ^^^^               ^^^
|> #include <sys/param.h>
|> #endif
|> 
|>    to detect if the code is being compiled on a 4.3 Net2 code base or
|>    newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and
|>    below).
|> 
|> #if (defined(BSD) && (BSD >= 199103))
                ^^^      ^^^
|> 
|>    to detect if the code is being compiled on a 4.4 code base or newer
|>    (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above).
|> 
|> #if (defined(BSD) && (BSD >= 199306))
                ^^^      ^^^

GCC cannot use any of the marked identifiers because they are in the
application's namespace.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: FreeBSD 4.0

[David O'Brien]

> |> #if (defined(__unix__) || defined(unix)) && !defined(USG)
>                                      ^^^^               ^^^
> |> #include <sys/param.h>

    /* :-) */
    #include "config.h"
    #ifdef HAVE_PARAM_H
    #include <sys/param.h>
    #endif

> |> #if (defined(BSD) && (BSD >= 199306))
>                 ^^^      ^^^
> 
> GCC cannot use any of the marked identifiers because they are in the
> application's namespace.

Reguardless, "BSD" is the approved way under BSD.  If an application
tries to define it, they will typically have problems compiling under
BSD.

Anyway GCC already uses symbols in the applications namespace:

    find . -type f | xargs grep 'f i386'
    ./gcc/libgcc2.c:#ifdef i386
    ./gcc/config/i386/xm-i386.h:#ifndef i386
 
-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Andreas Schwab]

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

"David O'Brien" <obrien@NUXI.com> writes:

|> > |> #if (defined(__unix__) || defined(unix)) && !defined(USG)
|> >                                      ^^^^               ^^^
|> > |> #include <sys/param.h>
|> 
|>     /* :-) */
|>     #include "config.h"
|>     #ifdef HAVE_PARAM_H
|>     #include <sys/param.h>
|>     #endif

We cannot use an config header in <stdarg.h>.  This header must be
absolutely namespace clean.  If you don't know what that means please read
the C standard.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: FreeBSD 4.0

[David O'Brien]

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

Andreas,

I'm sorry I don't know who you are (I guess I should go check the GCC web
pages...) but pleaes butt out.

Zack Weinberg <zack@bitmover.com> asked if there was any macro that all
4.4BSD-derived systems defined.  I answered it.


> We cannot use an config header in <stdarg.h>.

No shit.  Be a software engineer and engineer.  Have gcc-x.y/configure do
what ever way you want of including <sys/param.h> and testing for "BSD".
Then have it spit out "__44BSD_INSIDE", and have whatever later script do
or extract what ever Zack may want to do.


> This header must be absolutely namespace clean.  If you don't know what
> that means please read the C standard.

Yes I know what this means.  

> Andreas Schwab                                  "And now for something
> schwab@suse.de                                   completely different."
> SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

IMHO, you are not being helpful in this discussion, and since you
probably know more about non-BSD hosts than BSD hosts why are you
speaking out here??

-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Andreas Schwab]

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

"David O'Brien" <obrien@NUXI.com> writes:

|> Andreas,
|> 
|> I'm sorry I don't know who you are (I guess I should go check the GCC web
|> pages...) but pleaes butt out.
|> 
|> Zack Weinberg <zack@bitmover.com> asked if there was any macro that all
|> 4.4BSD-derived systems defined.  I answered it.

Please don't take this personal, but unfortunately your answer wasn't
appropriate in the context of a conforming C implementation.  The
<stdarg.h> and <stdlib.h> headers are very different from the files in gcc
source.  It is important to keep this distinction in mind, otherwise the
-ansi flags does not deserve its name.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: FreeBSD 4.0

[Andreas Schwab]

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

"David O'Brien" <obrien@NUXI.com> writes:

|> Andreas,
|> 
|> I'm sorry I don't know who you are (I guess I should go check the GCC web
|> pages...) but pleaes butt out.
|> 
|> Zack Weinberg <zack@bitmover.com> asked if there was any macro that all
|> 4.4BSD-derived systems defined.  I answered it.

Please don't take this personal, but unfortunately your answer wasn't
appropriate in the context of a conforming C implementation.  The
<stdarg.h> and <stdlib.h> headers are very different from the files in gcc
source.  It is important to keep this distinction in mind, otherwise the
-ansi flags does not deserve its name.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: FreeBSD 4.0

[David O'Brien]

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

Andreas,

I'm sorry I don't know who you are (I guess I should go check the GCC web
pages...) but pleaes butt out.

Zack Weinberg <zack@bitmover.com> asked if there was any macro that all
4.4BSD-derived systems defined.  I answered it.


> We cannot use an config header in <stdarg.h>.

No shit.  Be a software engineer and engineer.  Have gcc-x.y/configure do
what ever way you want of including <sys/param.h> and testing for "BSD".
Then have it spit out "__44BSD_INSIDE", and have whatever later script do
or extract what ever Zack may want to do.


> This header must be absolutely namespace clean.  If you don't know what
> that means please read the C standard.

Yes I know what this means.  

> Andreas Schwab                                  "And now for something
> schwab@suse.de                                   completely different."
> SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

IMHO, you are not being helpful in this discussion, and since you
probably know more about non-BSD hosts than BSD hosts why are you
speaking out here??

-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Andreas Schwab]

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

"David O'Brien" <obrien@NUXI.com> writes:

|> > |> #if (defined(__unix__) || defined(unix)) && !defined(USG)
|> >                                      ^^^^               ^^^
|> > |> #include <sys/param.h>
|> 
|>     /* :-) */
|>     #include "config.h"
|>     #ifdef HAVE_PARAM_H
|>     #include <sys/param.h>
|>     #endif

We cannot use an config header in <stdarg.h>.  This header must be
absolutely namespace clean.  If you don't know what that means please read
the C standard.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990915013954.D17808@dragon.nuxi.com >you write:
  > Anyway GCC already uses symbols in the applications namespace:
  > 
  >     find . -type f | xargs grep 'f i386'
  >     ./gcc/libgcc2.c:#ifdef i386
  >     ./gcc/config/i386/xm-i386.h:#ifndef i386
Just because gcc already does something that is wrong, does not mean we
should add new stuff that is also clearly wrong.

GCC has a lot of baggage from it's past;  we're trying to kill those things
which are clearly wrong and stupid as time permits.  If you want to be helpful
submit a patch to change those to __i386__.


jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990915013954.D17808@dragon.nuxi.com >you write:
  > Anyway GCC already uses symbols in the applications namespace:
  > 
  >     find . -type f | xargs grep 'f i386'
  >     ./gcc/libgcc2.c:#ifdef i386
  >     ./gcc/config/i386/xm-i386.h:#ifndef i386
Just because gcc already does something that is wrong, does not mean we
should add new stuff that is also clearly wrong.

GCC has a lot of baggage from it's past;  we're trying to kill those things
which are clearly wrong and stupid as time permits.  If you want to be helpful
submit a patch to change those to __i386__.


jeff

Re: FreeBSD 4.0

[David O'Brien]

> |> #if (defined(__unix__) || defined(unix)) && !defined(USG)
>                                      ^^^^               ^^^
> |> #include <sys/param.h>

    /* :-) */
    #include "config.h"
    #ifdef HAVE_PARAM_H
    #include <sys/param.h>
    #endif

> |> #if (defined(BSD) && (BSD >= 199306))
>                 ^^^      ^^^
> 
> GCC cannot use any of the marked identifiers because they are in the
> application's namespace.

Reguardless, "BSD" is the approved way under BSD.  If an application
tries to define it, they will typically have problems compiling under
BSD.

Anyway GCC already uses symbols in the applications namespace:

    find . -type f | xargs grep 'f i386'
    ./gcc/libgcc2.c:#ifdef i386
    ./gcc/config/i386/xm-i386.h:#ifndef i386
 
-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Andreas Schwab]

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

"David O'Brien" <obrien@NUXI.com> writes:

|> > Is there any macro which is defined by all 4.4-derived systems?
|> 
|> #if (defined(__unix__) || defined(unix)) && !defined(USG)
                                     ^^^^               ^^^
|> #include <sys/param.h>
|> #endif
|> 
|>    to detect if the code is being compiled on a 4.3 Net2 code base or
|>    newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and
|>    below).
|> 
|> #if (defined(BSD) && (BSD >= 199103))
                ^^^      ^^^
|> 
|>    to detect if the code is being compiled on a 4.4 code base or newer
|>    (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above).
|> 
|> #if (defined(BSD) && (BSD >= 199306))
                ^^^      ^^^

GCC cannot use any of the marked identifiers because they are in the
application's namespace.

Andreas.

-- 
Andreas Schwab                                  "And now for something
schwab@suse.de                                   completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Re: FreeBSD 4.0

[David O'Brien]

> Is there any macro which is defined by all 4.4-derived systems?

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif

   to detect if the code is being compiled on a 4.3 Net2 code base or
   newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 and
   below).

#if (defined(BSD) && (BSD >= 199103))

   to detect if the code is being compiled on a 4.4 code base or newer
   (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or above).

#if (defined(BSD) && (BSD >= 199306))

Re: FreeBSD 4.0

[David O'Brien]

> Because the "real" type is __gnuc_va_list.  Doing it your way won't do
> what you want.  I hope you don't have system headers that typedef
> _BSD_VA_LIST_ without reference to gcc's stdarg.h - 

    from /usr/include/machine/ansi.h

        #define _BSD_VA_LIST_   char *                  /* va_list */

There are no GCC headers in my base system.  We've never needed them, and
there are copyright issues anyway.


> for one thing, we probably just irrevocably broke them.

That is not good.  (doesn't anyone there have access to a BSD machine??)


> The problem with __gnuc_va_list is primarily aesthetic.  

If it is only aesthetics then lets leave it alone.

> Everyone has to agree on the underlying typedef name because of C++
> mangled names.  Therefore I would like the underlying typedef name to
> be compiler-neutral.  

If you want g++ compiled by someone under FreeBSD to work with the base
compiler, libs etc.  the type will need to be _BSD_VA_LIST_ (char *).


> People do want to use glibc with compilers other than gcc.

I don't care what other people do with glibc.
 
-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Zack Weinberg]

"David O'Brien" wrote:
> > Because the "real" type is __gnuc_va_list.  Doing it your way won't do
> > what you want.  I hope you don't have system headers that typedef
> > _BSD_VA_LIST_ without reference to gcc's stdarg.h - 
> 
>     from /usr/include/machine/ansi.h
> 
>         #define _BSD_VA_LIST_   char *                  /* va_list */
> 
> There are no GCC headers in my base system.  We've never needed them, and
> there are copyright issues anyway.

Do you have your own stdarg.h too?

This definition will not work with the new stdarg scheme.  gcc's
stdarg.h does

#ifndef __GNUC_VA_LIST
#define __GNUC_VA_LIST
typedef __builtin_va_list __gnuc_va_list;
#endif

__builtin_va_list is an opaque type which may be 'char *' deep inside,
but won't be compatible in the C sense with 'char *'.

Since it's a #define not a typedef, we can work around it:

#ifdef _BSD_VA_LIST_
#undef _BSD_VA_LIST_
#define _BSD_VA_LIST_ __gnuc_va_list
#endif

but that requires us to get machine/ansi.h included by stdarg.h.
Since that header is BSD specific, we go back to needing some
automatically defined macro that can be tested.  And I'm sorry, but
Andreas is right, we cannot use 'BSD'.  Suppose stdarg.h is the very
first header included by a user program.  Only the macros predefined
by the compiler are available, and those don't include BSD.  (It has
nothing to do with -ansi.)  gcc's stddef.h has the same problem and is
using

/* On 4.3bsd-net2, make sure ansi.h is included, so we have
   one less case to deal with in the following.  */
#if defined __BSD_NET2__ || defined ____386BSD____ \
    || defined __FreeBSD__ || defined __NetBSD__
#include <machine/ansi.h>
#endif

which looks pretty safe modulo the absence of __OpenBSD__...

I'd like to know what machine/ansi.h does on Alphas, where "char *"
doesn't work for va_list.

zw

Re: FreeBSD 4.0

[David O'Brien]

> > There are no GCC headers in my base system.  We've never needed them, and
> > there are copyright issues anyway.
> 
> Do you have your own stdarg.h too?

Yes.  Both /usr/include/stdarg.h and /usr/include/machine/stdarg.h, they
are identical files.  The following are from the 4.0 development branch.

i386 version:

    typedef char *va_list;

    #define	__va_size(type) \
	    (((sizeof(type) + sizeof(int) - 1) / sizeof(int)) * sizeof(int))

    #ifdef __GNUC__
        #define va_start(ap, last) \
	        ((ap) = (va_list)__builtin_next_arg(last))
    #else
        #define	va_start(ap, last) \
	        ((ap) = (va_list)&(last) + __va_size(last))
    #endif

    #define	va_arg(ap, type) \
	    (*(type *)((ap) += __va_size(type), (ap) - __va_size(type)))

    #define	va_end(ap)

Alpha version:

    #include <machine/ansi.h>

    #ifdef __lint__
    #define	__builtin_saveregs()		(0)
    #define	__builtin_classify_type(t)	(0)
    #endif

    typedef _BSD_VA_LIST_	va_list;

    #define	__va_size(type) \
	    (((sizeof(type) + sizeof(long) - 1) / sizeof(long)) * sizeof(long))

    #define	va_start(ap, last) \
	    (__builtin_next_arg(last), (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0)

    #define	__REAL_TYPE_CLASS	8
    #define	__va_arg_offset(ap, type)					\
	    ((__builtin_classify_type(*(type *)0) == __REAL_TYPE_CLASS &&	\
	        (ap).__offset <= (6 * 8) ? -(6 * 8) : 0) - __va_size(type))

    #define	va_arg(ap, type)						\
	    (*(type *)((ap).__offset += __va_size(type),			\
		       (ap).__base + (ap).__offset + __va_arg_offset(ap, type)))

    #define	va_end(ap)	((void)0)


> but that requires us to get machine/ansi.h included by stdarg.h.
> Since that header is BSD specific, we go back to needing some
> automatically defined macro that can be tested.  And I'm sorry, but
> Andreas is right, we cannot use 'BSD'.

Yes, I offered testing for "BSD" as something configure or any fix
includes scripts could do and so _something_inserted_here_ to deal with
the issue.

> #if defined __BSD_NET2__ || defined ____386BSD____ \
>     || defined __FreeBSD__ || defined __NetBSD__
> #include <machine/ansi.h>
> #endif

Yes, those are the only compiler/cpp defines you can be guarenteed of.
 
> which looks pretty safe modulo the absence of __OpenBSD__...
> 
> I'd like to know what machine/ansi.h does on Alphas, where "char *"
> doesn't work for va_list.

     typedef struct {
	     char *__base;
	     int __offset;
	     int __pad;
     } __va_list;
     #define	_BSD_VA_LIST_		__va_list	/* va_list */

-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Richard Henderson]

On Wed, Sep 15, 1999 at 10:24:03AM -0700, David O'Brien wrote:
>     #define	va_start(ap, last) \
> 	    (__builtin_next_arg(last), \
>	     (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0)

This won't work any longer, for multiple reasons, either on Alpha
or with any other target that passes arguments in registers in the
presence of varargs. 

One of the changes actually fixes bugs that show up under rare
conditions, so backward compatibility with old varargs headers
isn't an option.

Bottom line, with version 2.96 and later, you absolutely must use the
builtins.  Which means to me that you should just use gcc's stdarg.h
always.


r~

Re: FreeBSD 4.0

[Richard Henderson]

On Wed, Sep 15, 1999 at 10:24:03AM -0700, David O'Brien wrote:
>     #define	va_start(ap, last) \
> 	    (__builtin_next_arg(last), \
>	     (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0)

This won't work any longer, for multiple reasons, either on Alpha
or with any other target that passes arguments in registers in the
presence of varargs. 

One of the changes actually fixes bugs that show up under rare
conditions, so backward compatibility with old varargs headers
isn't an option.

Bottom line, with version 2.96 and later, you absolutely must use the
builtins.  Which means to me that you should just use gcc's stdarg.h
always.


r~

Re: FreeBSD 4.0

[David O'Brien]

> > There are no GCC headers in my base system.  We've never needed them, and
> > there are copyright issues anyway.
> 
> Do you have your own stdarg.h too?

Yes.  Both /usr/include/stdarg.h and /usr/include/machine/stdarg.h, they
are identical files.  The following are from the 4.0 development branch.

i386 version:

    typedef char *va_list;

    #define	__va_size(type) \
	    (((sizeof(type) + sizeof(int) - 1) / sizeof(int)) * sizeof(int))

    #ifdef __GNUC__
        #define va_start(ap, last) \
	        ((ap) = (va_list)__builtin_next_arg(last))
    #else
        #define	va_start(ap, last) \
	        ((ap) = (va_list)&(last) + __va_size(last))
    #endif

    #define	va_arg(ap, type) \
	    (*(type *)((ap) += __va_size(type), (ap) - __va_size(type)))

    #define	va_end(ap)

Alpha version:

    #include <machine/ansi.h>

    #ifdef __lint__
    #define	__builtin_saveregs()		(0)
    #define	__builtin_classify_type(t)	(0)
    #endif

    typedef _BSD_VA_LIST_	va_list;

    #define	__va_size(type) \
	    (((sizeof(type) + sizeof(long) - 1) / sizeof(long)) * sizeof(long))

    #define	va_start(ap, last) \
	    (__builtin_next_arg(last), (ap) = *(va_list *)__builtin_saveregs(), (ap).__pad = 0)

    #define	__REAL_TYPE_CLASS	8
    #define	__va_arg_offset(ap, type)					\
	    ((__builtin_classify_type(*(type *)0) == __REAL_TYPE_CLASS &&	\
	        (ap).__offset <= (6 * 8) ? -(6 * 8) : 0) - __va_size(type))

    #define	va_arg(ap, type)						\
	    (*(type *)((ap).__offset += __va_size(type),			\
		       (ap).__base + (ap).__offset + __va_arg_offset(ap, type)))

    #define	va_end(ap)	((void)0)


> but that requires us to get machine/ansi.h included by stdarg.h.
> Since that header is BSD specific, we go back to needing some
> automatically defined macro that can be tested.  And I'm sorry, but
> Andreas is right, we cannot use 'BSD'.

Yes, I offered testing for "BSD" as something configure or any fix
includes scripts could do and so _something_inserted_here_ to deal with
the issue.

> #if defined __BSD_NET2__ || defined ____386BSD____ \
>     || defined __FreeBSD__ || defined __NetBSD__
> #include <machine/ansi.h>
> #endif

Yes, those are the only compiler/cpp defines you can be guarenteed of.
 
> which looks pretty safe modulo the absence of __OpenBSD__...
> 
> I'd like to know what machine/ansi.h does on Alphas, where "char *"
> doesn't work for va_list.

     typedef struct {
	     char *__base;
	     int __offset;
	     int __pad;
     } __va_list;
     #define	_BSD_VA_LIST_		__va_list	/* va_list */

-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909151623.JAA02391@zack.bitmover.com >you write:
  > > There are no GCC headers in my base system.  We've never needed them, and
  > > there are copyright issues anyway.
  > 
  > Do you have your own stdarg.h too?
They may have their own stdarg.h, but we should not be using it.  We should
be using the gcc supplied stdarg.h & varargs.h.  This is related to the who
thread about how a port should never, ever override USER_H.

Actually, given the revamp of the varargs/stdarg stuff recently, now might
be as good a time as any to zap the USER_H overrides and arrange that they
can not come back since ports which are redefining USER_H probably don't
work right now anyway.

That will also root out problems with stddef.h since ports like FreeBSD, 
OpenBSD
and NetBSD will start using the one provided by gcc instead of their own.  
stddef.h has the header file that eventually sent me down the path of
redefining USER_H years ago.  FWIW, I believe the particular problem I was
working around has already been fixed.

The effected ports would be:

./alpha/t-interix:USER_H=$(LANG_EXTRA_HEADERS)
./pa/x-pa:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./i386/t-interix:USER_H=$(LANG_EXTRA_HEADERS)
./i386/x-dgux:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./m88k/x-dgux:USER_H =  $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./m88k/x-dguxbcs:USER_H =  $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./mips/x-netbsd:USER_H = $(srcdir)/ginclude/stdarg.h $(srcdir)/ginclude/varargs.h \
./t-freebsd:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./t-openbsd:USER_H = ${LANG_EXTRA_HEADERS}
And winnt I believe.

[ For those wondering about x-pa, that is for PAs running 4.3/4.4 BSD, not
  the widely more available hpux :-) ]
jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909151623.JAA02391@zack.bitmover.com >you write:
  > > There are no GCC headers in my base system.  We've never needed them, and
  > > there are copyright issues anyway.
  > 
  > Do you have your own stdarg.h too?
They may have their own stdarg.h, but we should not be using it.  We should
be using the gcc supplied stdarg.h & varargs.h.  This is related to the who
thread about how a port should never, ever override USER_H.

Actually, given the revamp of the varargs/stdarg stuff recently, now might
be as good a time as any to zap the USER_H overrides and arrange that they
can not come back since ports which are redefining USER_H probably don't
work right now anyway.

That will also root out problems with stddef.h since ports like FreeBSD, 
OpenBSD
and NetBSD will start using the one provided by gcc instead of their own.  
stddef.h has the header file that eventually sent me down the path of
redefining USER_H years ago.  FWIW, I believe the particular problem I was
working around has already been fixed.

The effected ports would be:

./alpha/t-interix:USER_H=$(LANG_EXTRA_HEADERS)
./pa/x-pa:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./i386/t-interix:USER_H=$(LANG_EXTRA_HEADERS)
./i386/x-dgux:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./m88k/x-dgux:USER_H =  $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./m88k/x-dguxbcs:USER_H =  $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./mips/x-netbsd:USER_H = $(srcdir)/ginclude/stdarg.h $(srcdir)/ginclude/varargs.h \
./t-freebsd:USER_H = $(EXTRA_HEADERS) $(LANG_EXTRA_HEADERS)
./t-openbsd:USER_H = ${LANG_EXTRA_HEADERS}
And winnt I believe.

[ For those wondering about x-pa, that is for PAs running 4.3/4.4 BSD, not
  the widely more available hpux :-) ]
jeff

Re: FreeBSD 4.0

[Zack Weinberg]

"David O'Brien" wrote:
> > Because the "real" type is __gnuc_va_list.  Doing it your way won't do
> > what you want.  I hope you don't have system headers that typedef
> > _BSD_VA_LIST_ without reference to gcc's stdarg.h - 
> 
>     from /usr/include/machine/ansi.h
> 
>         #define _BSD_VA_LIST_   char *                  /* va_list */
> 
> There are no GCC headers in my base system.  We've never needed them, and
> there are copyright issues anyway.

Do you have your own stdarg.h too?

This definition will not work with the new stdarg scheme.  gcc's
stdarg.h does

#ifndef __GNUC_VA_LIST
#define __GNUC_VA_LIST
typedef __builtin_va_list __gnuc_va_list;
#endif

__builtin_va_list is an opaque type which may be 'char *' deep inside,
but won't be compatible in the C sense with 'char *'.

Since it's a #define not a typedef, we can work around it:

#ifdef _BSD_VA_LIST_
#undef _BSD_VA_LIST_
#define _BSD_VA_LIST_ __gnuc_va_list
#endif

but that requires us to get machine/ansi.h included by stdarg.h.
Since that header is BSD specific, we go back to needing some
automatically defined macro that can be tested.  And I'm sorry, but
Andreas is right, we cannot use 'BSD'.  Suppose stdarg.h is the very
first header included by a user program.  Only the macros predefined
by the compiler are available, and those don't include BSD.  (It has
nothing to do with -ansi.)  gcc's stddef.h has the same problem and is
using

/* On 4.3bsd-net2, make sure ansi.h is included, so we have
   one less case to deal with in the following.  */
#if defined __BSD_NET2__ || defined ____386BSD____ \
    || defined __FreeBSD__ || defined __NetBSD__
#include <machine/ansi.h>
#endif

which looks pretty safe modulo the absence of __OpenBSD__...

I'd like to know what machine/ansi.h does on Alphas, where "char *"
doesn't work for va_list.

zw

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990915011710.B25121@relay.nuxi.com >you write:
  > There are no GCC headers in my base system.  We've never needed them, and
  > there are copyright issues anyway.
What copyright issues?


jeff

Re: FreeBSD 4.0

[Zack Weinberg]

Jeffrey A Law wrote:
>   In message < 19990915011710.B25121@relay.nuxi.com >you write:
>   > There are no GCC headers in my base system.  We've never needed them, and
>   > there are copyright issues anyway.
> What copyright issues?

There is no explicit license/copyright statement at the top of
stddef.h or stdarg.h or whatever.  Someone could easily have been
misled into thinking that they were GPLed and would infect programs.

We should probably put something like the libstdc++ "special
exception" paragraph at the top.

zw

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909201624.JAA16030@zack.bitmover.com >you write:
  > Jeffrey A Law wrote:
  > >   In message < 19990915011710.B25121@relay.nuxi.com >you write:
  > >   > There are no GCC headers in my base system.  We've never needed them,
  >  and
  > >   > there are copyright issues anyway.
  > > What copyright issues?
  > 
  > There is no explicit license/copyright statement at the top of
  > stddef.h or stdarg.h or whatever.  Someone could easily have been
  > misled into thinking that they were GPLed and would infect programs.
  > 
  > We should probably put something like the libstdc++ "special
  > exception" paragraph at the top.
Sigh.  There are times when the laxness of the previous 10 years really
bugs me.  This is one of them.

Start with the template in libgcc2.c and change it to deal with header
files instead of libraries.

Do you want to do this, or should I (or if someone else wants it, speak up).


jeff

Re: FreeBSD 4.0

[Zack Weinberg]

Jeffrey A Law wrote:
>   In message < 199909201624.JAA16030@zack.bitmover.com >you write:
>   > Jeffrey A Law wrote:
>   > >   In message < 19990915011710.B25121@relay.nuxi.com >you write:
>   > >   > There are no GCC headers in my base system.  We've never needed the
> m,
>   >  and
>   > >   > there are copyright issues anyway.
>   > > What copyright issues?
>   > 
>   > There is no explicit license/copyright statement at the top of
>   > stddef.h or stdarg.h or whatever.  Someone could easily have been
>   > misled into thinking that they were GPLed and would infect programs.
>   > 
>   > We should probably put something like the libstdc++ "special
>   > exception" paragraph at the top.
> Sigh.  There are times when the laxness of the previous 10 years really
> bugs me.  This is one of them.
> 
> Start with the template in libgcc2.c and change it to deal with header
> files instead of libraries.
> 
> Do you want to do this, or should I (or if someone else wants it, speak up).

Patch appended.

We still have to deal with float.h and limits.h which are generated.
I personally think we should dump those files, but that's a larger
issue.

zw

1999-09-20 10:13 -0700  Zack Weinberg  <zack@bitmover.com>

	* iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add
	copyright notice and special exception to GPL.

===================================================================
Index: iso646.h
--- iso646.h	1998/12/16 21:19:18	1.2
+++ iso646.h	1999/09/20 17:11:58
@@ -1,5 +1,36 @@
-/* Macros for C programs written in national variants of ISO 646.  */
+/* Copyright (C) 1997, 1999 Free Software Foundation, Inc.
 
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.9  Alternative spellings  <iso646.h>
+ */
+
+#ifndef _ISO646_H
+#define _ISO646_H
+
 #ifndef __cplusplus
 #define and	&&
 #define and_eq	&=
@@ -12,4 +43,6 @@
 #define or_eq	|=
 #define xor	^
 #define xor_eq	^=
+#endif
+
 #endif
===================================================================
Index: stdarg.h
--- stdarg.h	1999/09/14 23:30:44	1.10
+++ stdarg.h	1999/09/20 17:11:58
@@ -1,9 +1,33 @@
-/* stdarg.h for GNU.
+/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc.
 
-   Note that the type used in va_arg is supposed to match the
-   actual type **after default promotions**.
-   Thus, va_arg (..., short) is not valid.  */
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
 
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.15  Variable arguments  <stdarg.h>
+ */
+
 #ifndef _STDARG_H
 #ifndef _ANSI_STDARG_H_
 #ifndef __need___va_list
@@ -22,6 +46,10 @@ typedef __builtin_va_list __gnuc_va_list
 /* Define the standard macros for the user,
    if this invocation was from the user program.  */
 #ifdef _STDARG_H
+
+/* Note that the type used in va_arg is supposed to match the
+   actual type **after default promotions**.
+   Thus, va_arg (..., short) is not valid.  */
 
 #define va_start(v,l)	__builtin_stdarg_start(&(v),l)
 #define va_end		__builtin_va_end
===================================================================
Index: stdbool.h
--- stdbool.h	1999/08/29 15:46:14	1.3
+++ stdbool.h	1999/09/20 17:11:58
@@ -1,6 +1,35 @@
-/* stdbool.h for GNU.  */
-#ifndef __STDBOOL_H__
-#define __STDBOOL_H__	1
+/* Copyright (C) 1998, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.16  Boolean type and values  <stdbool.h>
+ */
+
+#ifndef _STDBOOL_H
+#define _STDBOOL_H
 
 /* The type `_Bool' must promote to `int' or `unsigned int'.  The constants
    `true' and `false' must have the value 0 and 1 respectively.  */
===================================================================
Index: stddef.h
--- stddef.h	1998/12/16 21:19:25	1.4
+++ stddef.h	1999/09/20 17:11:58
@@ -1,3 +1,32 @@
+/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.17  Common definitions  <stddef.h>
+ */
 #if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
      && !defined(__STDDEF_H__)) \
     || defined(__need_wchar_t) || defined(__need_size_t) \
===================================================================
Index: varargs.h
--- varargs.h	1999/09/14 23:30:44	1.12
+++ varargs.h	1999/09/20 17:11:58
@@ -1,4 +1,28 @@
-/* Record that this is varargs.h; this turns off stdarg.h.  */
+/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
 
 #ifndef _VARARGS_H
 #define _VARARGS_H

Re: FreeBSD 4.0

[Richard Earnshaw]

> Start with the template in libgcc2.c and change it to deal with header
> files instead of libraries.
>  

But what if I want to pass my code through lint?  I've now got to find 
another set of header files to replace these or I risk bringing my own 
code under the GPL (the special exemption clause only applies if I'm using 
the header for compiling with GCC).

OK, I guess I'm probably still better off than I was before (when 
technically, since there was no usage statement, I probably had no rights 
to use the file at all), but this may still be a problem in a BSD system.

Re: FreeBSD 4.0

[Zack Weinberg]

Richard Earnshaw wrote:
> 
> > Start with the template in libgcc2.c and change it to deal with header
> > files instead of libraries.
> >  
> 
> But what if I want to pass my code through lint?  I've now got to find 
> another set of header files to replace these or I risk bringing my own 
> code under the GPL (the special exemption clause only applies if I'm using 
> the header for compiling with GCC).

lint doesn't generate an executable, so you're fine.

You'd have a problem if you were to use the header in conjunction with
a different *compiler*, such as lcc - but I believe our position is
that lcc needs to provide its own copies of these headers anyway.

I'd be fine with generalizing the special exception to any compiler,
but that's not for me to decide.

zw

Re: FreeBSD 4.0

[Zack Weinberg]

Richard Earnshaw wrote:
> 
> > Start with the template in libgcc2.c and change it to deal with header
> > files instead of libraries.
> >  
> 
> But what if I want to pass my code through lint?  I've now got to find 
> another set of header files to replace these or I risk bringing my own 
> code under the GPL (the special exemption clause only applies if I'm using 
> the header for compiling with GCC).

lint doesn't generate an executable, so you're fine.

You'd have a problem if you were to use the header in conjunction with
a different *compiler*, such as lcc - but I believe our position is
that lcc needs to provide its own copies of these headers anyway.

I'd be fine with generalizing the special exception to any compiler,
but that's not for me to decide.

zw

Re: FreeBSD 4.0

[Horst von Brand]

Richard Earnshaw <rearnsha@arm.com> said:
> > Start with the template in libgcc2.c and change it to deal with header
> > files instead of libraries.

> But what if I want to pass my code through lint?  I've now got to find 
> another set of header files to replace these or I risk bringing my own 
> code under the GPL (the special exemption clause only applies if I'm using 
> the header for compiling with GCC).

AFAIU, if you pass the code + headers through <whatever> (<whatever> !=
gcc), you have to abide by the GPL with the output. I.e., _if_ you
distribute it further, you _must_ provide sources. I suspect you don't want
to distribute lint output...

BTW, this again leaves a gray area for files that are first preprocessed
somehow, for example with something like Oracle's Pro*C that handles SQL
embedded in C/C++, giving C/C++ files that are then compiled. AFAIR, Pro*C
_does_ #include files when preprocessing.

IANAL, just a satisfied GNU software user.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: FreeBSD 4.0

[Chris G. Demetriou]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> I suspect you don't want
> to distribute lint output...

In fact, he may.  For instance, say you build a lint library
(llib-lfoo.ln) for distribution.  (Say you're making an SDK for some
proprietary software, and want to include a lint library so that
people can lint their code?)

NetBSD, for instance, ships lint libraries for all of the system
libraries.  It's reasonable to expect a vendor of an SDK to want to do
the same...


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.

Re: FreeBSD 4.0

[Chris G. Demetriou]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> I suspect you don't want
> to distribute lint output...

In fact, he may.  For instance, say you build a lint library
(llib-lfoo.ln) for distribution.  (Say you're making an SDK for some
proprietary software, and want to include a lint library so that
people can lint their code?)

NetBSD, for instance, ships lint libraries for all of the system
libraries.  It's reasonable to expect a vendor of an SDK to want to do
the same...


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.

Re: FreeBSD 4.0

[Horst von Brand]

Richard Earnshaw <rearnsha@arm.com> said:
> > Start with the template in libgcc2.c and change it to deal with header
> > files instead of libraries.

> But what if I want to pass my code through lint?  I've now got to find 
> another set of header files to replace these or I risk bringing my own 
> code under the GPL (the special exemption clause only applies if I'm using 
> the header for compiling with GCC).

AFAIU, if you pass the code + headers through <whatever> (<whatever> !=
gcc), you have to abide by the GPL with the output. I.e., _if_ you
distribute it further, you _must_ provide sources. I suspect you don't want
to distribute lint output...

BTW, this again leaves a gray area for files that are first preprocessed
somehow, for example with something like Oracle's Pro*C that handles SQL
embedded in C/C++, giving C/C++ files that are then compiled. AFAIR, Pro*C
_does_ #include files when preprocessing.

IANAL, just a satisfied GNU software user.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: FreeBSD 4.0

[Richard Earnshaw]

> Start with the template in libgcc2.c and change it to deal with header
> files instead of libraries.
>  

But what if I want to pass my code through lint?  I've now got to find 
another set of header files to replace these or I risk bringing my own 
code under the GPL (the special exemption clause only applies if I'm using 
the header for compiling with GCC).

OK, I guess I'm probably still better off than I was before (when 
technically, since there was no usage statement, I probably had no rights 
to use the file at all), but this may still be a problem in a BSD system.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909201715.KAA17676@zack.bitmover.com >you write:
  > > Sigh.  There are times when the laxness of the previous 10 years really
  > > bugs me.  This is one of them.
  > > 
  > > Start with the template in libgcc2.c and change it to deal with header
  > > files instead of libraries.
  > > 
  > > Do you want to do this, or should I (or if someone else wants it, speak u
  > p).
  > 
  > Patch appended.
  > 
  > We still have to deal with float.h and limits.h which are generated.
  > I personally think we should dump those files, but that's a larger
  > issue.
  > 
  > zw
  > 
  > 1999-09-20 10:13 -0700  Zack Weinberg  <zack@bitmover.com>
  > 
  > 	* iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add
  > 	copyright notice and special exception to GPL.
Approved.

Note that float.h and limits.h are generated from source files within gcc
itself, so we can easily add the right copyright to them.

As for deleting them, let's take that up later.  We've got enough major
projects in progress already (and queued) that I'd like to see finished
before we do something like deleting those files.

Thanks,
jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909201715.KAA17676@zack.bitmover.com >you write:
  > > Sigh.  There are times when the laxness of the previous 10 years really
  > > bugs me.  This is one of them.
  > > 
  > > Start with the template in libgcc2.c and change it to deal with header
  > > files instead of libraries.
  > > 
  > > Do you want to do this, or should I (or if someone else wants it, speak u
  > p).
  > 
  > Patch appended.
  > 
  > We still have to deal with float.h and limits.h which are generated.
  > I personally think we should dump those files, but that's a larger
  > issue.
  > 
  > zw
  > 
  > 1999-09-20 10:13 -0700  Zack Weinberg  <zack@bitmover.com>
  > 
  > 	* iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add
  > 	copyright notice and special exception to GPL.
Approved.

Note that float.h and limits.h are generated from source files within gcc
itself, so we can easily add the right copyright to them.

As for deleting them, let's take that up later.  We've got enough major
projects in progress already (and queued) that I'd like to see finished
before we do something like deleting those files.

Thanks,
jeff

Re: FreeBSD 4.0

[Zack Weinberg]

Jeffrey A Law wrote:
>   In message < 199909201624.JAA16030@zack.bitmover.com >you write:
>   > Jeffrey A Law wrote:
>   > >   In message < 19990915011710.B25121@relay.nuxi.com >you write:
>   > >   > There are no GCC headers in my base system.  We've never needed the
> m,
>   >  and
>   > >   > there are copyright issues anyway.
>   > > What copyright issues?
>   > 
>   > There is no explicit license/copyright statement at the top of
>   > stddef.h or stdarg.h or whatever.  Someone could easily have been
>   > misled into thinking that they were GPLed and would infect programs.
>   > 
>   > We should probably put something like the libstdc++ "special
>   > exception" paragraph at the top.
> Sigh.  There are times when the laxness of the previous 10 years really
> bugs me.  This is one of them.
> 
> Start with the template in libgcc2.c and change it to deal with header
> files instead of libraries.
> 
> Do you want to do this, or should I (or if someone else wants it, speak up).

Patch appended.

We still have to deal with float.h and limits.h which are generated.
I personally think we should dump those files, but that's a larger
issue.

zw

1999-09-20 10:13 -0700  Zack Weinberg  <zack@bitmover.com>

	* iso646.h, stdarg.h, stdbool.h, stddef.h, varargs.h: Add
	copyright notice and special exception to GPL.

===================================================================
Index: iso646.h
--- iso646.h	1998/12/16 21:19:18	1.2
+++ iso646.h	1999/09/20 17:11:58
@@ -1,5 +1,36 @@
-/* Macros for C programs written in national variants of ISO 646.  */
+/* Copyright (C) 1997, 1999 Free Software Foundation, Inc.
 
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.9  Alternative spellings  <iso646.h>
+ */
+
+#ifndef _ISO646_H
+#define _ISO646_H
+
 #ifndef __cplusplus
 #define and	&&
 #define and_eq	&=
@@ -12,4 +43,6 @@
 #define or_eq	|=
 #define xor	^
 #define xor_eq	^=
+#endif
+
 #endif
===================================================================
Index: stdarg.h
--- stdarg.h	1999/09/14 23:30:44	1.10
+++ stdarg.h	1999/09/20 17:11:58
@@ -1,9 +1,33 @@
-/* stdarg.h for GNU.
+/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc.
 
-   Note that the type used in va_arg is supposed to match the
-   actual type **after default promotions**.
-   Thus, va_arg (..., short) is not valid.  */
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
 
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.15  Variable arguments  <stdarg.h>
+ */
+
 #ifndef _STDARG_H
 #ifndef _ANSI_STDARG_H_
 #ifndef __need___va_list
@@ -22,6 +46,10 @@ typedef __builtin_va_list __gnuc_va_list
 /* Define the standard macros for the user,
    if this invocation was from the user program.  */
 #ifdef _STDARG_H
+
+/* Note that the type used in va_arg is supposed to match the
+   actual type **after default promotions**.
+   Thus, va_arg (..., short) is not valid.  */
 
 #define va_start(v,l)	__builtin_stdarg_start(&(v),l)
 #define va_end		__builtin_va_end
===================================================================
Index: stdbool.h
--- stdbool.h	1999/08/29 15:46:14	1.3
+++ stdbool.h	1999/09/20 17:11:58
@@ -1,6 +1,35 @@
-/* stdbool.h for GNU.  */
-#ifndef __STDBOOL_H__
-#define __STDBOOL_H__	1
+/* Copyright (C) 1998, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.16  Boolean type and values  <stdbool.h>
+ */
+
+#ifndef _STDBOOL_H
+#define _STDBOOL_H
 
 /* The type `_Bool' must promote to `int' or `unsigned int'.  The constants
    `true' and `false' must have the value 0 and 1 respectively.  */
===================================================================
Index: stddef.h
--- stddef.h	1998/12/16 21:19:25	1.4
+++ stddef.h	1999/09/20 17:11:58
@@ -1,3 +1,32 @@
+/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
+
+/*
+ * ISO C Standard:  7.17  Common definitions  <stddef.h>
+ */
 #if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
      && !defined(__STDDEF_H__)) \
     || defined(__need_wchar_t) || defined(__need_size_t) \
===================================================================
Index: varargs.h
--- varargs.h	1999/09/14 23:30:44	1.12
+++ varargs.h	1999/09/20 17:11:58
@@ -1,4 +1,28 @@
-/* Record that this is varargs.h; this turns off stdarg.h.  */
+/* Copyright (C) 1989, 1997, 1998, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* As a special exception, if you include this header file into source
+   files compiled by GCC, this header file does not by itself cause
+   the resulting executable to be covered by the GNU General Public
+   License.  This exception does not however invalidate any other
+   reasons why the executable file might be covered by the GNU General
+   Public License.  */
 
 #ifndef _VARARGS_H
 #define _VARARGS_H

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909201624.JAA16030@zack.bitmover.com >you write:
  > Jeffrey A Law wrote:
  > >   In message < 19990915011710.B25121@relay.nuxi.com >you write:
  > >   > There are no GCC headers in my base system.  We've never needed them,
  >  and
  > >   > there are copyright issues anyway.
  > > What copyright issues?
  > 
  > There is no explicit license/copyright statement at the top of
  > stddef.h or stdarg.h or whatever.  Someone could easily have been
  > misled into thinking that they were GPLed and would infect programs.
  > 
  > We should probably put something like the libstdc++ "special
  > exception" paragraph at the top.
Sigh.  There are times when the laxness of the previous 10 years really
bugs me.  This is one of them.

Start with the template in libgcc2.c and change it to deal with header
files instead of libraries.

Do you want to do this, or should I (or if someone else wants it, speak up).


jeff

Re: FreeBSD 4.0

[Zack Weinberg]

Jeffrey A Law wrote:
>   In message < 19990915011710.B25121@relay.nuxi.com >you write:
>   > There are no GCC headers in my base system.  We've never needed them, and
>   > there are copyright issues anyway.
> What copyright issues?

There is no explicit license/copyright statement at the top of
stddef.h or stdarg.h or whatever.  Someone could easily have been
misled into thinking that they were GPLed and would infect programs.

We should probably put something like the libstdc++ "special
exception" paragraph at the top.

zw

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990915011710.B25121@relay.nuxi.com >you write:
  > There are no GCC headers in my base system.  We've never needed them, and
  > there are copyright issues anyway.
What copyright issues?


jeff

Re: FreeBSD 4.0

[David O'Brien]

> Because the "real" type is __gnuc_va_list.  Doing it your way won't do
> what you want.  I hope you don't have system headers that typedef
> _BSD_VA_LIST_ without reference to gcc's stdarg.h - 

    from /usr/include/machine/ansi.h

        #define _BSD_VA_LIST_   char *                  /* va_list */

There are no GCC headers in my base system.  We've never needed them, and
there are copyright issues anyway.


> for one thing, we probably just irrevocably broke them.

That is not good.  (doesn't anyone there have access to a BSD machine??)


> The problem with __gnuc_va_list is primarily aesthetic.  

If it is only aesthetics then lets leave it alone.

> Everyone has to agree on the underlying typedef name because of C++
> mangled names.  Therefore I would like the underlying typedef name to
> be compiler-neutral.  

If you want g++ compiled by someone under FreeBSD to work with the base
compiler, libs etc.  the type will need to be _BSD_VA_LIST_ (char *).


> People do want to use glibc with compilers other than gcc.

I don't care what other people do with glibc.
 
-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Zack Weinberg]

"David O'Brien" wrote:
> > May I suggest that stdarg.h/varargs.h be modified to #define
> > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
> > limit it to FreeBSD?  
> 
> Why not do it the other way around?
> 
>     #define __gnuc_va_list _BSD_VA_LIST_

Because the "real" type is __gnuc_va_list.  Doing it your way won't do
what you want.  I hope you don't have system headers that typedef
_BSD_VA_LIST_ without reference to gcc's stdarg.h - for one thing, we
probably just irrevocably broke them.

> Please, please lets not require the dinking of many system headers.
> Please also remember GCC is the base compiler in BSD and the number of
> things that have to be changed when native'ifing the compiler the better.

I believe #define _BSD_VA_LIST_ __gnuc_va_list will solve your problem
without any dinking of BSD libc headers.

> > (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
> > than adding stuff to fixinc.
> 
> This is a 4.4BSD thing.  It thus affects all of BSD.

Is there any macro which is defined by all 4.4-derived systems?

> > For complicated reasons related to similar interactions with glibc's
> > headers, I'd personally like to see the typedef name be __va_list, and
> > __gnuc_va_list a #define as well.
> 
> Can you explain these interactions?  I really doubt the BSD headers are
> as intertwined.

The intertwining with glibc is not as bad as you might think, and
__gnuc_va_list is actually the least bad part.  For real issues, try
to figure out what wint_t is doing in stddef.h, or how limits.h works.

The problem with __gnuc_va_list is primarily aesthetic.  Everyone has
to agree on the underlying typedef name because of C++ mangled names.
Therefore I would like the underlying typedef name to be
compiler-neutral.  People do want to use glibc with compilers other
than gcc.

zw

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990914231414.B17808@dragon.nuxi.com >you write:
  > > May I suggest that stdarg.h/varargs.h be modified to #define
  > > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
  > > limit it to FreeBSD?  
  > 
  > Why not do it the other way around?
  > 
  >     #define __gnuc_va_list _BSD_VA_LIST_
  > 
  > Please, please lets not require the dinking of many system headers.
  > Please also remember GCC is the base compiler in BSD and the number of
  > things that have to be changed when native'ifing the compiler the better.
That seems backwards.

When doing varargs/stdargs we absolutely do not want to be using system
definitions.  Even if the system compiler is gcc.

  > > (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
  > > than adding stuff to fixinc.
  > 
  > This is a 4.4BSD thing.  It thus affects all of BSD.
Be careful with that statement, while they all come from the same lineage,
each has hacked things up in their own special way.  And they're currently
treating USER_H and fixinc issues differently.

jeff

Re: FreeBSD 4.0

[David O'Brien]

> When doing varargs/stdargs we absolutely do not want to be using system
> definitions.  Even if the system compiler is gcc.

Can't this cause incompatibilities with libs and .o's compiled with the
base compiler?

-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990915022452.F17808@dragon.nuxi.com >you write:
  > > When doing varargs/stdargs we absolutely do not want to be using system
  > > definitions.  Even if the system compiler is gcc.
  > 
  > Can't this cause incompatibilities with libs and .o's compiled with the
  > base compiler?
If the underlying structures for va_list change, yes, but then again, in that
case you're hosed beyond belief anyway.

jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990915022452.F17808@dragon.nuxi.com >you write:
  > > When doing varargs/stdargs we absolutely do not want to be using system
  > > definitions.  Even if the system compiler is gcc.
  > 
  > Can't this cause incompatibilities with libs and .o's compiled with the
  > base compiler?
If the underlying structures for va_list change, yes, but then again, in that
case you're hosed beyond belief anyway.

jeff

Re: FreeBSD 4.0

[David O'Brien]

> When doing varargs/stdargs we absolutely do not want to be using system
> definitions.  Even if the system compiler is gcc.

Can't this cause incompatibilities with libs and .o's compiled with the
base compiler?

-- 
-- David    (obrien@NUXI.com)

Re: FreeBSD 4.0

[Bruce Korb]

Loren James Rittle wrote:
> Hi Bruce,
> 
> The issue is that stdio.h isn't the only system header under [Free]BSD
> that uses the _BSD_VA_LIST_ define.  Basically, approximately 10 other
> system header files need the same treatment as stdio.h.
> 
> In your opinion, should all those other headers be processed just like
> stdio.h?  Or, do you need more input on the matter?
> 
> There is another camp that dislikes this approach since they want to
> use gcc as the default compiler on the system and really want
> _BSD_VA_LIST_ to appear in the /usr/include version of the headers.

First off, I am strongly in the camp that says the fewer headers
that get secreted off some place the better.  In other words,
if the standard BSD compiler is GCC, then the standard BSD headers
should be compatible with it.

From the perspective that the future will be compatible, the
remaining question is what to do on older systems that use _BSD_VA_LIST_.
The most straght forward answer is:  do that which has the smallest
impact while still being certain to not break other implementations.
Since I do not know the exact usage of the _BSD_VA_LIST_ token, I hesitate
to propose a solution.  But the solution should vanish in the next few
decades as the old implementations die away :-).

In other words, fix the old systems with fixinc and the new ones with
source changes.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 37E00F41.AF49518@datadesign.com >you write:
  > First off, I am strongly in the camp that says the fewer headers
  > that get secreted off some place the better.  In other words,
  > if the standard BSD compiler is GCC, then the standard BSD headers
  > should be compatible with it.
But, unfortunately, header requirements change over time.  This is precisely
the problem we have had with the *BSD* systems over the years.

Back in 1991 or so I put in a change which made GCC avoid installing its 
own internal header files for "Net-2" systems (upon which all the *BSD variants
are derived.

That turned out to be a huge, unbelievably stupid, thing to do.  Why?  Because
when we needed to provide a magic symbol (I believe in stddef.h) to ensure
that C++ adhered to the proper definition of NULL the *BSD systems did not
get that definition.

Or another example would be the need to massage math.h because it had
"struct exception" in it and "exception" became a reserved word for C++.
 


  > >From the perspective that the future will be compatible,
That is not an assumption we can safely make because the requirements do
change over time and GCC needs to continue to work when those requirements
change.

  > The most straght forward answer is:  do that which has the smallest
  > impact while still being certain to not break other implementations.
I certainly agree with this.  However, it has to include installation of the
GCC header files, now and in the future.

jeff

Re: FreeBSD 4.0

[Marc Espie]

In article < 14810.937440488@upchuck.cygnus.com > you write:
>  In message < 37E00F41.AF49518@datadesign.com >you write:
>  > First off, I am strongly in the camp that says the fewer headers
>  > that get secreted off some place the better.  In other words,
>  > if the standard BSD compiler is GCC, then the standard BSD headers
>  > should be compatible with it.
>But, unfortunately, header requirements change over time.  This is precisely
>the problem we have had with the *BSD* systems over the years.

>Back in 1991 or so I put in a change which made GCC avoid installing its 
>own internal header files for "Net-2" systems (upon which all the *BSD variants
>are derived.

>That turned out to be a huge, unbelievably stupid, thing to do.  Why?  Because
>when we needed to provide a magic symbol (I believe in stddef.h) to ensure
>that C++ adhered to the proper definition of NULL the *BSD systems did not
>get that definition.

As far as OpenBSD goes, we are willing to fix our header files over time.
The NULL issue is now solved, and everything will be alright in that regards
for 2.6.

I'm even in the process of trying to replace (cast)(value) in the 
include files by macros that read __static_cast(cast, value).

I also would like to thoroughly annotate math functions with
__attribute__((const)) when I can. I'm still a bit unclear whether a function
that may fault with a SIGFPE, such as atan, is a good candidate for 
__attribute__((const)) or not.

>  > >From the perspective that the future will be compatible,
>That is not an assumption we can safely make because the requirements do
>change over time and GCC needs to continue to work when those requirements
>change.

As long as `new' requirements stay reasonably clear, this is not such a
large problem...  what bites is not having clear requirements, or not being
up to speed yet, as occurred for the __null issue.
In fact, this is simpler work than fixincludes, since
I am in a position to fix one set of headers without having to care about
the rest.

We can provide header archives to install with the compiler, if updates
are needed.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909160846.KAA29697@quatramaran.ens.fr >you write:
  > As far as OpenBSD goes, we are willing to fix our header files over time.
  > The NULL issue is now solved, and everything will be alright in that
  > regards for 2.6.
That doesn't matter.  GCC still needs to work on those systems where you have
not updated your header files.  Or if we find another need to update a header
file it is not acceptable to have to wait for another OpenBSD release to fix
the header files.

Quite simply, the USER_H overrides are wrong and must go.  Period.


jeff

Re: FreeBSD 4.0

[Marc Espie]

In article < 16930.937487529@upchuck.cygnus.com > you write:
>  In message < 199909160846.KAA29697@quatramaran.ens.fr >you write:
>  > As far as OpenBSD goes, we are willing to fix our header files over time.
>  > The NULL issue is now solved, and everything will be alright in that
>  > regards for 2.6.
>That doesn't matter.  GCC still needs to work on those systems where you have
>not updated your header files.  Or if we find another need to update a header
>file it is not acceptable to have to wait for another OpenBSD release to fix
>the header files.

>Quite simply, the USER_H overrides are wrong and must go.  Period.

No, there are two issues at work.

I concur that, if the end user want to fiddle with a newer gcc snapshot,
USER_H is in the way.

HOWEVER, from the OpenBSD release point of view, we want to go on fixing
include files, and provide our own.

I believe that both goals are not contradictory. Specifically, when 
installed as the system compiler, gcc WILL use the system includes, and
it should work with them.   If fixincludes has to tweak those headers,
OR if gcc should head its own headers, well... then it's a bug in our
system headers, and we want to fix that...  worse than that: it's a deadly
bug; there are parts of the system, such as the kernel, which are built
-nostdinc, and which desperately need the system headers to be correct.

If a user wants to install a more recent gcc to fiddle with it (or a gcc on an
ancient system that, for some strange reason, they don't want to upgrade), 
no problem with having it install its more modern version of include files 
and running fixincludes and so on...

If you prefer, there are two software packages to maintain here: gcc and
OpenBSD. 

Your goal is to ensure gcc's headers and fixincludes work.
My goal is to ensure OpenBSD system headers are fine.

Allow me to defend my own turf...

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909161441.QAA03626@quatramaran.ens.fr >you write:
  > >Quite simply, the USER_H overrides are wrong and must go.  Period.
  > 
  > No, there are two issues at work.
  > 
  > I concur that, if the end user want to fiddle with a newer gcc snapshot,
  > USER_H is in the way.
  > 
  > HOWEVER, from the OpenBSD release point of view, we want to go on fixing
  > include files, and provide our own.
  > 
  > I believe that both goals are not contradictory. Specifically, when 
  > installed as the system compiler, gcc WILL use the system includes, and
  > it should work with them.   If fixincludes has to tweak those headers,
  > OR if gcc should head its own headers, well... then it's a bug in our
  > system headers, and we want to fix that...  worse than that: it's a deadly
  > bug; there are parts of the system, such as the kernel, which are built
  > -nostdinc, and which desperately need the system headers to be correct.
No.  Absolutely not.  Overriding USER_H is wrong. Period.  No ifs, ands or
buts.

It will go away.  I strongly recommend you stop using it.

Like so many of the other braindamaged things you're doing because you think
things need to work "specially" because gcc can be the system compiler are
dumb and can be easily avoided.  By not doing all those dumb and special things
I think you'll find that over time that things will "just work" instead of
having to continually tweak it.

I'll repeat, overriding USER_H is absolutely and completely wrong in all
situations.  Period.  This is not subject to debate.


jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909161441.QAA03626@quatramaran.ens.fr >you write:
  > >Quite simply, the USER_H overrides are wrong and must go.  Period.
  > 
  > No, there are two issues at work.
  > 
  > I concur that, if the end user want to fiddle with a newer gcc snapshot,
  > USER_H is in the way.
  > 
  > HOWEVER, from the OpenBSD release point of view, we want to go on fixing
  > include files, and provide our own.
  > 
  > I believe that both goals are not contradictory. Specifically, when 
  > installed as the system compiler, gcc WILL use the system includes, and
  > it should work with them.   If fixincludes has to tweak those headers,
  > OR if gcc should head its own headers, well... then it's a bug in our
  > system headers, and we want to fix that...  worse than that: it's a deadly
  > bug; there are parts of the system, such as the kernel, which are built
  > -nostdinc, and which desperately need the system headers to be correct.
No.  Absolutely not.  Overriding USER_H is wrong. Period.  No ifs, ands or
buts.

It will go away.  I strongly recommend you stop using it.

Like so many of the other braindamaged things you're doing because you think
things need to work "specially" because gcc can be the system compiler are
dumb and can be easily avoided.  By not doing all those dumb and special things
I think you'll find that over time that things will "just work" instead of
having to continually tweak it.

I'll repeat, overriding USER_H is absolutely and completely wrong in all
situations.  Period.  This is not subject to debate.


jeff

Re: FreeBSD 4.0

[Marc Espie]

In article < 16930.937487529@upchuck.cygnus.com > you write:
>  In message < 199909160846.KAA29697@quatramaran.ens.fr >you write:
>  > As far as OpenBSD goes, we are willing to fix our header files over time.
>  > The NULL issue is now solved, and everything will be alright in that
>  > regards for 2.6.
>That doesn't matter.  GCC still needs to work on those systems where you have
>not updated your header files.  Or if we find another need to update a header
>file it is not acceptable to have to wait for another OpenBSD release to fix
>the header files.

>Quite simply, the USER_H overrides are wrong and must go.  Period.

No, there are two issues at work.

I concur that, if the end user want to fiddle with a newer gcc snapshot,
USER_H is in the way.

HOWEVER, from the OpenBSD release point of view, we want to go on fixing
include files, and provide our own.

I believe that both goals are not contradictory. Specifically, when 
installed as the system compiler, gcc WILL use the system includes, and
it should work with them.   If fixincludes has to tweak those headers,
OR if gcc should head its own headers, well... then it's a bug in our
system headers, and we want to fix that...  worse than that: it's a deadly
bug; there are parts of the system, such as the kernel, which are built
-nostdinc, and which desperately need the system headers to be correct.

If a user wants to install a more recent gcc to fiddle with it (or a gcc on an
ancient system that, for some strange reason, they don't want to upgrade), 
no problem with having it install its more modern version of include files 
and running fixincludes and so on...

If you prefer, there are two software packages to maintain here: gcc and
OpenBSD. 

Your goal is to ensure gcc's headers and fixincludes work.
My goal is to ensure OpenBSD system headers are fine.

Allow me to defend my own turf...

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909160846.KAA29697@quatramaran.ens.fr >you write:
  > As far as OpenBSD goes, we are willing to fix our header files over time.
  > The NULL issue is now solved, and everything will be alright in that
  > regards for 2.6.
That doesn't matter.  GCC still needs to work on those systems where you have
not updated your header files.  Or if we find another need to update a header
file it is not acceptable to have to wait for another OpenBSD release to fix
the header files.

Quite simply, the USER_H overrides are wrong and must go.  Period.


jeff

Re: FreeBSD 4.0

[Marc Espie]

In article < 14810.937440488@upchuck.cygnus.com > you write:
>  In message < 37E00F41.AF49518@datadesign.com >you write:
>  > First off, I am strongly in the camp that says the fewer headers
>  > that get secreted off some place the better.  In other words,
>  > if the standard BSD compiler is GCC, then the standard BSD headers
>  > should be compatible with it.
>But, unfortunately, header requirements change over time.  This is precisely
>the problem we have had with the *BSD* systems over the years.

>Back in 1991 or so I put in a change which made GCC avoid installing its 
>own internal header files for "Net-2" systems (upon which all the *BSD variants
>are derived.

>That turned out to be a huge, unbelievably stupid, thing to do.  Why?  Because
>when we needed to provide a magic symbol (I believe in stddef.h) to ensure
>that C++ adhered to the proper definition of NULL the *BSD systems did not
>get that definition.

As far as OpenBSD goes, we are willing to fix our header files over time.
The NULL issue is now solved, and everything will be alright in that regards
for 2.6.

I'm even in the process of trying to replace (cast)(value) in the 
include files by macros that read __static_cast(cast, value).

I also would like to thoroughly annotate math functions with
__attribute__((const)) when I can. I'm still a bit unclear whether a function
that may fault with a SIGFPE, such as atan, is a good candidate for 
__attribute__((const)) or not.

>  > >From the perspective that the future will be compatible,
>That is not an assumption we can safely make because the requirements do
>change over time and GCC needs to continue to work when those requirements
>change.

As long as `new' requirements stay reasonably clear, this is not such a
large problem...  what bites is not having clear requirements, or not being
up to speed yet, as occurred for the __null issue.
In fact, this is simpler work than fixincludes, since
I am in a position to fix one set of headers without having to care about
the rest.

We can provide header archives to install with the compiler, if updates
are needed.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 37E00F41.AF49518@datadesign.com >you write:
  > First off, I am strongly in the camp that says the fewer headers
  > that get secreted off some place the better.  In other words,
  > if the standard BSD compiler is GCC, then the standard BSD headers
  > should be compatible with it.
But, unfortunately, header requirements change over time.  This is precisely
the problem we have had with the *BSD* systems over the years.

Back in 1991 or so I put in a change which made GCC avoid installing its 
own internal header files for "Net-2" systems (upon which all the *BSD variants
are derived.

That turned out to be a huge, unbelievably stupid, thing to do.  Why?  Because
when we needed to provide a magic symbol (I believe in stddef.h) to ensure
that C++ adhered to the proper definition of NULL the *BSD systems did not
get that definition.

Or another example would be the need to massage math.h because it had
"struct exception" in it and "exception" became a reserved word for C++.
 


  > >From the perspective that the future will be compatible,
That is not an assumption we can safely make because the requirements do
change over time and GCC needs to continue to work when those requirements
change.

  > The most straght forward answer is:  do that which has the smallest
  > impact while still being certain to not break other implementations.
I certainly agree with this.  However, it has to include installation of the
GCC header files, now and in the future.

jeff

Re: FreeBSD 4.0

[Bruce Korb]

Loren James Rittle wrote:
> Hi Bruce,
> 
> The issue is that stdio.h isn't the only system header under [Free]BSD
> that uses the _BSD_VA_LIST_ define.  Basically, approximately 10 other
> system header files need the same treatment as stdio.h.
> 
> In your opinion, should all those other headers be processed just like
> stdio.h?  Or, do you need more input on the matter?
> 
> There is another camp that dislikes this approach since they want to
> use gcc as the default compiler on the system and really want
> _BSD_VA_LIST_ to appear in the /usr/include version of the headers.

First off, I am strongly in the camp that says the fewer headers
that get secreted off some place the better.  In other words,
if the standard BSD compiler is GCC, then the standard BSD headers
should be compatible with it.

From the perspective that the future will be compatible, the
remaining question is what to do on older systems that use _BSD_VA_LIST_.
The most straght forward answer is:  do that which has the smallest
impact while still being certain to not break other implementations.
Since I do not know the exact usage of the _BSD_VA_LIST_ token, I hesitate
to propose a solution.  But the solution should vanish in the next few
decades as the old implementations die away :-).

In other words, fix the old systems with fixinc and the new ones with
source changes.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 19990914231414.B17808@dragon.nuxi.com >you write:
  > > May I suggest that stdarg.h/varargs.h be modified to #define
  > > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
  > > limit it to FreeBSD?  
  > 
  > Why not do it the other way around?
  > 
  >     #define __gnuc_va_list _BSD_VA_LIST_
  > 
  > Please, please lets not require the dinking of many system headers.
  > Please also remember GCC is the base compiler in BSD and the number of
  > things that have to be changed when native'ifing the compiler the better.
That seems backwards.

When doing varargs/stdargs we absolutely do not want to be using system
definitions.  Even if the system compiler is gcc.

  > > (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
  > > than adding stuff to fixinc.
  > 
  > This is a 4.4BSD thing.  It thus affects all of BSD.
Be careful with that statement, while they all come from the same lineage,
each has hacked things up in their own special way.  And they're currently
treating USER_H and fixinc issues differently.

jeff

Re: FreeBSD 4.0

[David O'Brien]

> May I suggest that stdarg.h/varargs.h be modified to #define
> _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
> limit it to FreeBSD?  

Why not do it the other way around?

    #define __gnuc_va_list _BSD_VA_LIST_

Please, please lets not require the dinking of many system headers.
Please also remember GCC is the base compiler in BSD and the number of
things that have to be changed when native'ifing the compiler the better.


> (Is this needed by Net/OpenBSD too?)  This is simpler and less fragile
> than adding stuff to fixinc.

This is a 4.4BSD thing.  It thus affects all of BSD.

 
> For complicated reasons related to similar interactions with glibc's
> headers, I'd personally like to see the typedef name be __va_list, and
> __gnuc_va_list a #define as well.

Can you explain these interactions?  I really doubt the BSD headers are
as intertwined.

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909150601.XAA22053@zack.bitmover.com >you write:
  > May I suggest that stdarg.h/varargs.h be modified to #define
  > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
  > limit it to FreeBSD?  (Is this needed by Net/OpenBSD too?)  This is
  > simpler and less fragile than adding stuff to fixinc.
NetBSD and OpenBSD will need the same treatment when we kill the amazingly
braindamaged USER_H override in their makefile fragments.


jeff

Re: FreeBSD 4.0

[Jeffrey A Law]

  In message < 199909150601.XAA22053@zack.bitmover.com >you write:
  > May I suggest that stdarg.h/varargs.h be modified to #define
  > _BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
  > limit it to FreeBSD?  (Is this needed by Net/OpenBSD too?)  This is
  > simpler and less fragile than adding stuff to fixinc.
NetBSD and OpenBSD will need the same treatment when we kill the amazingly
braindamaged USER_H override in their makefile fragments.


jeff

Re: FreeBSD 4.0

[Zack Weinberg]

Loren James Rittle wrote:
> 
> Unfortunately (although extremely minor), that means that until I get
> around to investigating the root issue in fixinc, any C++ code that
> relies on system headers which use _BSD_VA_LIST_ instead of va_list
> (not including stdio.h which is now correctly fixed) will fail with
> errors of this form:
> 
> cannot convert `void *' to `char *' for argument `X' to `foo(...)'
> 
> Richard, is it your position that all system headers must be fixed to
> only reference __gnuc_va_list instead of va_list and/or
> system-specific macros such as _BSD_VA_LIST_ (as was historically used
> by BSD systems)?  If so, then fixinc's rule to mung _BSD_VA_LIST_ into
> __gnuc_va_list must be expanded to operate on 10-15 other standard BSD
> system headers...

May I suggest that stdarg.h/varargs.h be modified to #define
_BSD_VA_LIST_ to __gnuc_va_list, possibly with appropriate ifdefs to
limit it to FreeBSD?  (Is this needed by Net/OpenBSD too?)  This is
simpler and less fragile than adding stuff to fixinc.

For complicated reasons related to similar interactions with glibc's
headers, I'd personally like to see the typedef name be __va_list, and
__gnuc_va_list a #define as well.

zw

Re: FreeBSD 4.0

[Wes Morgan]

On Wed, 15 Sep 1999, Loren James Rittle wrote:

> Cool!  If you have upgraded past gcc_ss_19990913 and picked up
> Richard's latest changes, then I can now confirm (since I just
> finished a bootstrap on the mainline with his changes) that the
> gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer
> needed (since he removed the code that those patches affected ;-)!

Same thing here. Using the CVS stdarg and varargs, applying the patch only
to t-freebsd, I get a successfull build of the C and C++ compilers (I 
don't bother with any of the others). I don't have dejagnu installed for  
fbsd though, so I don't know the results of a make check.

WM

-- 
The difference between genius and stupidity is that genius has its limits.
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: FreeBSD 4.0

[Wes Morgan]

On Wed, 15 Sep 1999, Loren James Rittle wrote:

> Cool!  If you have upgraded past gcc_ss_19990913 and picked up
> Richard's latest changes, then I can now confirm (since I just
> finished a bootstrap on the mainline with his changes) that the
> gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer
> needed (since he removed the code that those patches affected ;-)!

Same thing here. Using the CVS stdarg and varargs, applying the patch only
to t-freebsd, I get a successfull build of the C and C++ compilers (I 
don't bother with any of the others). I don't have dejagnu installed for  
fbsd though, so I don't know the results of a make check.

WM

-- 
The difference between genius and stupidity is that genius has its limits.
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: FreeBSD 4.0

[Loren James Rittle]

Wes Morgan wrote:

> Trying to build the latest CVS snapshot under freebsd 4.0 fails with these
> errors:

...
> include/stdio.h:245: parse error before `__gnuc_va_list'
...

> There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some
> of the changelogs, but I haven't seen anything conclusive... Is this a
> known problem, or is my CVS tree out of sync somehow? Or maybe I need to
> set some different CFLAGS?

I have built gcc_ss_19990913 on FreeBSD 3.2-RELEASE with the patches
in http://egcs.cygnus.com/ml/gcc-patches/1999-08/msg00728.html (they
have been *REQUIRED* on FreeBSD for some time).  The issue is that
ports may no longer override USER_T in order to keep fixinc from running.

Richard Henderson wrote:

> I just checked in a much simplified version of stdarg.h.
> Would you send me a preprocessed copy and we can figure
> out what went wrong.

Cool!  If you have upgraded past gcc_ss_19990913 and picked up
Richard's latest changes, then I can now confirm (since I just
finished a bootstrap on the mainline with his changes) that the
gcc/ginclude/stdarg.h and gcc/ginclude/varargs.h patches are no longer
needed (since he removed the code that those patches affected ;-)!

Unfortunately (although extremely minor), that means that until I get
around to investigating the root issue in fixinc, any C++ code that
relies on system headers which use _BSD_VA_LIST_ instead of va_list
(not including stdio.h which is now correctly fixed) will fail with
errors of this form:

cannot convert `void *' to `char *' for argument `X' to `foo(...)'

Richard, is it your position that all system headers must be fixed to
only reference __gnuc_va_list instead of va_list and/or
system-specific macros such as _BSD_VA_LIST_ (as was historically used
by BSD systems)?  If so, then fixinc's rule to mung _BSD_VA_LIST_ into
__gnuc_va_list must be expanded to operate on 10-15 other standard BSD
system headers...

Wes, if you could tell me if the referenced patches work for you under
FreeBSD 4.0, that could be helpful.

Regards,
Loren

FreeBSD 4.0

[Wes Morgan]

Trying to build the latest CVS snapshot under freebsd 4.0 fails with these
errors:

In file included from ../../egcs/gcc/libgcc2.c:1408:
include/stdio.h:245: parse error before `__gnuc_va_list'
include/stdio.h:246: parse error before `__gnuc_va_list'
include/stdio.h:247: parse error before `__gnuc_va_list'
include/stdio.h:311: parse error before `__gnuc_va_list'
include/stdio.h:313: parse error before `__gnuc_va_list'
include/stdio.h:315: parse error before `__gnuc_va_list'
include/stdio.h:316: parse error before `__gnuc_va_list'
include/stdio.h:346: parse error before `__gnuc_va_list'
*** Error code 1


There are a few mentions of fixing _BSD_VA_LIST_ to __gnuc_va_list in some
of the changelogs, but I haven't seen anything conclusive... Is this a
known problem, or is my CVS tree out of sync somehow? Or maybe I need to
set some different CFLAGS?

WM

-- 
The difference between genius and stupidity is that genius has its limits.
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!