Conerned about lack of detail in ChangeLog/commit messges

Conerned about lack of detail in ChangeLog/commit messges

[David O'Brien]

Rev 1.26 of gengenrtl.c changed the gen* utils from writing to a file to
writing to stdout.  I noticed this when upgrading the FreeBSD stock
compiler from 2.95.2 to 2.96 and all of a sudden my bmake Makefile broke.

The ChangeLog entry for this change is:

    revision 1.26
    date: 1999/09/07 05:47:55;  author: law;  state: Exp;  lines: +142 -130
    Merge in gcc2-ss-010999

This lack of detail was very annoying as I spent a lot more time than
needed to verify that the differences I noticed in gen* were intentional.
The diff from 1.25 to 1.26 is large enough to explain the change.
Looking at ``cvs log gengenrtl.c'' I was unable to find any details on
the "gcc2-ss-010999" branch.

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

Re: Conerned about lack of detail in ChangeLog/commit messges

[Martin v. Loewis]

> The ChangeLog entry for this change is:
> 
>     revision 1.26
>     date: 1999/09/07 05:47:55;  author: law;  state: Exp;  lines: +142 -130
>     Merge in gcc2-ss-010999
> 
> This lack of detail was very annoying as I spent a lot more time than
> needed to verify that the differences I noticed in gen* were intentional.
> The diff from 1.25 to 1.26 is large enough to explain the change.
> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on
> the "gcc2-ss-010999" branch.

Isn't the log message self-explanatory, at least to informed gcc
contributors? That is a merge from gcc2, which used to a project
different from the one that provided the current CVS archives.

One of the major reasons for starting the egcs project was that it was
so extremely difficult to locate the gcc2 source code - something
which you are suffering from right now. The problem has been corrected
today, but can't be corrected retroactively (sp?).

Regards,
Martin

Re: Conerned about lack of detail in ChangeLog/commit messges

[David Edelsohn]

>>>>> "David O'Brien" writes:

David> The ChangeLog entry for this change is:

David> revision 1.26
David> date: 1999/09/07 05:47:55;  author: law;  state: Exp;  lines: +142 -130
David> Merge in gcc2-ss-010999

David> This lack of detail was very annoying as I spent a lot more time than
David> needed to verify that the differences I noticed in gen* were intentional.
David> The diff from 1.25 to 1.26 is large enough to explain the change.
David> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on
David> the "gcc2-ss-010999" branch.

	What you list above is the CVS entry, not the ChangeLog entry.
The entry in ChangeLog.2 says:

        * Merge from gcc2 snapshot Jan 9, 1999.  See FSFChangeLog for
        details.

Did you check FSFChangeLog (which contains the ChangeLog entries from the
gcc2 development which was occurring in parallel with EGCS?  The actual
various ChangeLog files are the historical repository, not CVS log
entries.

David

Re: Conerned about lack of detail in ChangeLog/commit messges

[David O'Brien]

On Fri, Jun 09, 2000 at 11:30:21AM -0400, David Edelsohn wrote:
> David> The diff from 1.25 to 1.26 is large enough to explain the change.
> David> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on
> David> the "gcc2-ss-010999" branch.
> 
> 	What you list above is the CVS entry, not the ChangeLog entry.
> The entry in ChangeLog.2 says:
> 
>         * Merge from gcc2 snapshot Jan 9, 1999.  See FSFChangeLog for
>         details.

Sorry, I was under the impression (from what I've seen in other CVS
commit messages) that the ChangeLog text is in the commit message.  IMHO
CVS logs are much easier to use to find the notes on a change than the
ChangeLog's.  

GCC ChangeLog's do not use a consistent date format, thus it is time
consuming to find the entry you are looking for as searching in your
favorite viewer isn't as good as it could be.  Nor does this ChangeLog
entry contain the name of the modified file as it should.  In this case,
I could not use any of the CVS message text in searching for the
ChangeLog entry except for the word "Merge".

 
> Did you check FSFChangeLog (which contains the ChangeLog entries from the
> gcc2 development

I did not.  I forgot that there was a FSFChangeLog vs. just ChangeLog.  I
guess I'm just used to the other projects who's CVS repo I work with.
There is an emphasis on detail in commit messages to assist people in
finding out about changes.  I'm surprised the message above didn't at
least tell people to see the FSFChangeLog (and give the applicable date
range) for details on the changes.

> The actual various ChangeLog files are the historical repository, not
> CVS log entries.

Yes I know.  IMHO now that the world has access to the CVS logs, they
could be better used now.

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

Re: Conerned about lack of detail in ChangeLog/commit messges

[Nick Burrett]

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

> On Fri, Jun 09, 2000 at 11:30:21AM -0400, David Edelsohn wrote:
> > David> The diff from 1.25 to 1.26 is large enough to explain the change.
> > David> Looking at ``cvs log gengenrtl.c'' I was unable to find any details on
> > David> the "gcc2-ss-010999" branch.
> > 
> > 	What you list above is the CVS entry, not the ChangeLog entry.
> > The entry in ChangeLog.2 says:
> > 
> >         * Merge from gcc2 snapshot Jan 9, 1999.  See FSFChangeLog for
> >         details.
> 
> Sorry, I was under the impression (from what I've seen in other CVS
> commit messages) that the ChangeLog text is in the commit message.  IMHO
> CVS logs are much easier to use to find the notes on a change than the
> ChangeLog's.  
> 
> GCC ChangeLog's do not use a consistent date format, thus it is time
> consuming to find the entry you are looking for as searching in your
> favorite viewer isn't as good as it could be.  Nor does this ChangeLog
> entry contain the name of the modified file as it should.  In this case,
> I could not use any of the CVS message text in searching for the
> ChangeLog entry except for the word "Merge".

This would be easily resolvable if in future the ChangeLog date and e-mail
header were included in the CVS commit messages.  It would make things
much easier to cross-reference since the CVS date is always going to be
slightly different to the ChangeLog date.  I'm not sure if CVSweb would
cope very well with this though.
 
>  
> > Did you check FSFChangeLog (which contains the ChangeLog entries from the
> > gcc2 development
> 
> I did not.  I forgot that there was a FSFChangeLog vs. just ChangeLog.  I
> guess I'm just used to the other projects who's CVS repo I work with.
> There is an emphasis on detail in commit messages to assist people in
> finding out about changes.  I'm surprised the message above didn't at
> least tell people to see the FSFChangeLog (and give the applicable date
> range) for details on the changes.

Perhaps it would have been better to include the FSFChangeLog directly
into the ChangeLog under a single entry in the same way that is done for
older branches.  It's a bit late in the day for that though.

> > The actual various ChangeLog files are the historical repository, not
> > CVS log entries.
> 
> Yes I know.  IMHO now that the world has access to the CVS logs, they
> could be better used now.

I think it is much easier to look at a ChangeLog than look at the CVS logs
for individual files.  The `cvs log' has to keep on being re-generated,
the ChangeLog is there, fast to access, and provides a good overview
of all files changed, rather than just a few.
 

Nick.

Re: Conerned about lack of detail in ChangeLog/commit messges

[David O'Brien]

On Fri, Jun 09, 2000 at 05:13:08PM +0100, Nick Burrett wrote:
> I think it is much easier to look at a ChangeLog than look at the CVS logs
> for individual files.

It might help if the date format for ChangeLog entries were
standardized upon.

> The `cvs log' has to keep on being re-generated, the ChangeLog is
> there, fast to access, and provides a good overview of all files
> changed, rather than just a few.

I love my DSL, what can I say. :-)   I do see your point.  But, I am
usually doing the opposite -- I just want to know about the chagnes to a
single file.  I find that a single file's change can get lost in the
sometimes huge ChangeLog entries.
  
-- 
-- David    (obrien@NUXI.com)

Re: Conerned about lack of detail in ChangeLog/commit messges

[Marc Espie]

Yeah, gcc doesn't make a sensible utilisation of cvs, does it ?
At least it's somewhat different from most other projects that use it
that I know.

The proposal of generating the cvs logs from the Changelog is somewhat 
backwards.  It would probably be much, much simpler to generate a ChangeLog
out of cvs commit messages. In fact, this is how other projects usually 
do it. Cvs does yield fairly nice commit messages.  That would solve
one specific problem: all files changed would be automatically mentioned
in the commit message. The format can be tweaked afterwards to be as 
compliant with the Changelog entry as one wishes...

In fact, I would very much prefer having the Changelog match the committed
date, not some other somewhat artificial dates. There are lots of other ways
to refer to a patch, the entry in the gcc-patches archive comes to mind.

And David is quite correct that using the ChangeLog to browse through the
history of one file is a pain... One loses most of the features that make
cvs useful.  For instance, `cvs annotate' is almost useless on gcc, 
since it is very hard to go back from gcc revisions to Changelog entry.

I understand that this is somewhat hard to change, but consider it.
There might be a good reason why other projects are actually USING cvs for
day-to-day work, might there not ? :)

[PATCH] rs6000.c ELF bits inclusion

[David O'Brien]

W/o this change one must include config/svr4.h rather than
config/elfos.h, which is just wrong on BSD hosts as config/svr4.h
contains bits specific to that platform vs. the generic ELF object
format.


2001-05-02  David O'Brien  <obrien@FreeBSD.org>

	* config/elfos.h, config/rs6000/rs6000.c: Use USING_ELFOS_H rather than
	USING_SVR4_H as the code is ELF specific, not SVR4 platform specific.



Index: config/elfos.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/elfos.h,v
retrieving revision 1.25.2.1
diff -u -r1.25.2.1 elfos.h
--- elfos.h	2001/04/16 18:25:40	1.25.2.1
+++ elfos.h	2001/05/03 01:19:09
@@ -21,6 +21,9 @@
 the Free Software Foundation, 59 Temple Place - Suite 330,
 Boston, MA 02111-1307, USA.  */
 
+/* Define a symbol indicating that we are using elfos.h.  */
+#define USING_ELFOS_H
+
 /* The prefix to add to user-visible assembler symbols.
 
    For ELF systems the convention is *not* to prepend a leading
Index: config/rs6000/rs6000.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.167.2.2
diff -u -r1.167.2.2 rs6000.c
--- rs6000.c	2001/05/02 21:34:15	1.167.2.2
+++ rs6000.c	2001/05/03 01:19:10
@@ -75,7 +75,7 @@
    get the address of the GOT section */
 int rs6000_pic_labelno;
 
-#ifdef USING_SVR4_H
+#ifdef USING_ELFOS_H
 /* Which abi to adhere to */
 const char *rs6000_abi_name = RS6000_ABI_NAME;
 
@@ -442,7 +442,7 @@
 	    }
 	}
 
-#ifdef USING_SVR4_H
+#ifdef USING_ELFOS_H
       switch (rs6000_sdata)
 	{
 	case SDATA_NONE: fprintf (file, "%s -msdata=none", start); start = ""; break;
@@ -7497,7 +7497,7 @@
    Do not define this macro if you put all constants in the read-only
    data section.  */
 
-#ifdef USING_SVR4_H
+#ifdef USING_ELFOS_H
 
 void
 rs6000_select_rtx_section (mode, x)

Re: [PATCH] rs6000.c ELF bits inclusion

[David Edelsohn]

> W/o this change one must include config/svr4.h rather than
> config/elfos.h, which is just wrong on BSD hosts as config/svr4.h
> contains bits specific to that platform vs. the generic ELF object
> format.

	What do you mean by "contains bits specific to that platform"?
SVR4 is not a platform?  For PowerPC, the only defined ABIs are PowerOpen
(AIX and related to Darwin) and SVR4 (including eABI).  eABI is a
derivative of SVR4.  There are no other ABIs.  What other "generic" ELF
object format is FreeBSD for PowerPC using that SVR4 is a conflict?

David

Re: [PATCH] rs6000.c ELF bits inclusion

[David O'Brien]

On Wed, May 02, 2001 at 11:06:57PM -0400, David Edelsohn wrote:
> > W/o this change one must include config/svr4.h rather than
> > config/elfos.h, which is just wrong on BSD hosts as config/svr4.h
> > contains bits specific to that platform vs. the generic ELF object
> > format.
> 
> 	What do you mean by "contains bits specific to that platform"?
> SVR4 is not a platform?  For PowerPC, the only defined ABIs are PowerOpen
> (AIX and related to Darwin) and SVR4 (including eABI).  eABI is a
> derivative of SVR4.  There are no other ABIs.  What other "generic" ELF
> object format is FreeBSD for PowerPC using that SVR4 is a conflict?

Did you look at config/svr4.h???


    #define WORD_SWITCH_TAKES_ARG(STR)			\
     (DEFAULT_WORD_SWITCH_TAKES_ARG (STR)			\
      && strcmp (STR, "Tdata") && strcmp (STR, "Ttext")	\
      && strcmp (STR, "Tbss"))

No BSD ELF implementation supports these.

    #undef  ASM_SPEC
    #define ASM_SPEC \
      "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}"

This ASM spec is wrong.


    #define MD_EXEC_PREFIX "/usr/ccs/bin/"
    #define MD_STARTFILE_PREFIX "/usr/ccs/lib/"

These MD spec are *WAY* wrong.  This is a SVR4 _platform_ setting.  Where
in any ELF ABI is this spec specified?

    /* Provide a LIB_SPEC appropriate for svr4.  Here we tack on the default
       standard C library (unless we are building a shared library).  */

    #undef	LIB_SPEC
    #define LIB_SPEC "%{!shared:%{!symbolic:-lc}}"

As the comment says, "appropriate for svr4", not all ELF platforms and
certainly not FreeBSD.

    /* Provide an ENDFILE_SPEC appropriate for svr4.  Here we tack on our own
    ...
    #define ENDFILE_SPEC "crtend.o%s %{pg:gcrtn.o%s}%{!pg:crtn.o%s}"

Again, this is a bogus setting to force down ever ELF implementations
throat.
I need this one "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s",
and why should I have to #undef the world?

    /* Gcc automatically adds in one of the files /usr/ccs/lib/values-Xc.o,
       /usr/ccs/lib/values-Xa.o, or /usr/ccs/lib/values-Xt.o for each final
       link step (depending upon the other gcc options selected, such as
       -traditional and -ansi).  These files each contain one (initialized)
       copy of a special variable called `_lib_version'.  Each one of these
       files has `_lib_version' initialized to a different (enum) value.
       The SVR4 library routines query the value of `_lib_version' at run
       to decide how they should behave.  Specifically, they decide (based
       upon the value of `_lib_version') if they will act in a strictly ANSI
       conforming manner or not.  */

    #undef	STARTFILE_SPEC
    #define STARTFILE_SPEC "%{!shared: \

I won't even go into how this is very much a system implimentation
setting is only appropriate for "true-blue" generic SVR4 implementations.

    /* Define the actual types of some ANSI-mandated types.  (These
       definitions should work for most SVR4 systems).  */

systems => platforms to me.

Re: [PATCH] rs6000.c ELF bits inclusion

[David Edelsohn]

	Isn't this a question of whether config/svr4.h assumes to much?

	Why is the right solution to change rs6000.c?  Maybe it is or
maybe it isn't.  To me this is a broader design question than FreeBSD
relying directly upon elfos.h and sweeping the changes under the rug.

	config/freebsd.h is duplicating pieces of config/svr4.h.  This
causes a maintenance problem.  Is there no way to separate the
system-specific pieces of config/svr4.h from the ABI-specific pieces so
that FreeBSD could shared the latter with other SVR4-based system?

David

Re: [PATCH] rs6000.c ELF bits inclusion

[David O'Brien]

On Wed, May 02, 2001 at 11:52:33PM -0400, David Edelsohn wrote:
> 	Isn't this a question of whether config/svr4.h assumes to much?

Well... it used to, but that's why elfos.h was created.  The object
format is named "ELF", not "SVR4" (or "SYSV4").  Thus the generic object
file format specifications were pulled out of config/svr4.h. I(FreeBSD)
am not an AT&T/USL/NOVELL/SCO/CALDERA OS.  I don't follow their file
system layouts, nor their command-line options.  I do share their object
file format.  Ie. the ELF gABI does apply to me and SVR4.

Thus I feel "elfos" is a fine name for the object file bits than "svr4",
but I really don't care what you call it.  As long as there is a
difference between object file bits and system/platform implementation
bits.  `elfos.h' isn't perfect yet, as it still has too much of svr4.h
left in it, but I hope to clean up the CVS conflicts soon in my elfos.h
where I fixed this.  (also there are things in elfos.h that need to be in
<arch>/elf.h, as alpha/elf.h has to undo thing in elfos.h)

It is my strong opinion that every arch should have a config/<arch>/elf.h
header also, to teak things in the applicable ELF psABI.  We have this
for alpha and i386 (although it would be very nice to move
config/i386/i386elf.h to config/i386/elf.h, so that the rule is every ELF
platform includes 
"elfos.h ${platform}.h ${arch}/elf.h ${arch}/${platform}.h".

 
> 	Why is the right solution to change rs6000.c?

In this case, because rs6000.c shouldn't care that it is being compiled
for an AT&T/USL/NOVELL/SCO/CALDERA OS, but rather an ELF binary file
format one.


> maybe it isn't.  To me this is a broader design question than FreeBSD
> relying directly upon elfos.h and sweeping the changes under the rug.

Actually many things include config/svr4.h and then undoes what svr4.h
does.  This is simply because many of the maintainers haven't yet cleaned
up their files.  The gcc/config/ header include spaghetti is still alive
and I untangle it when I discover it and it is easy for me to test that I
have not problem something in the untangle.

 
> 	config/freebsd.h is duplicating pieces of config/svr4.h.

If they are line-for-line duplications, then the bits should be moved to
elfos.h if they are truly generic ELF related.  Otherwise there is no
big deal in this -- FreeBSD sits _beside_ SVR4 as a target.


> Is there no way to separate the
> system-specific pieces of config/svr4.h from the ABI-specific pieces so
> that FreeBSD could shared the latter with other SVR4-based system?

Yes, elfos.h and <arch>/elf.h.  Is there some reason this is not
suffient?

-- 
-- David  (obrien@FreeBSD.org)

Re: [PATCH] rs6000.c ELF bits inclusion

[David O'Brien]

On Wed, May 02, 2001 at 06:21:28PM -0700, David O'Brien wrote:
> 2001-05-02  David O'Brien  <obrien@FreeBSD.org>
> 
> 	* config/elfos.h, config/rs6000/rs6000.c: Use USING_ELFOS_H rather than
> 	USING_SVR4_H as the code is ELF specific, not SVR4 platform specific.

This patch allows me to do what I need.  Are you OK with it, or is there
another way you would like to see the problem solved?  I really do not
want to include config/svr4.h.

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

Re: [PATCH] rs6000.c ELF bits inclusion

[David Edelsohn]

>>>>> "David O'Brien" writes:

David> This patch allows me to do what I need.  Are you OK with it, or is there
David> another way you would like to see the problem solved?  I really do not
David> want to include config/svr4.h.

	I do not believe that it is productive for FreeBSD to have its
own, slightly different ABI.  FreeBSD likely will discourage more
potential users by being slightly incompatible than it gains for any
perceived improvement over the standard.  This design argument does not
seem to be effective with you.

	"... allows me to do what I need" is not a very compelling
argument that a patch is correct or should be approved, IMHO.  From my
perspective, it seems that you expediently want to solve the symptom of
your problem and not your problem.

	Because this patch is small and localized and this discussion no
longer seems to be productive, I am not going to object to the rs6000.c
change.  I suspect that you will have to return to this issue again (and
again) and eventually will need to solve it correctly.  Someone else with
authority for config/elfos.h needs to approve that part of the change.

David

Re: [PATCH] rs6000.c ELF bits inclusion

[David O'Brien]

On Thu, May 03, 2001 at 07:03:53PM -0400, David Edelsohn wrote:
> >>>>> "David O'Brien" writes:
> 
> David> This patch allows me to do what I need.  Are you OK with it, or is there
> David> another way you would like to see the problem solved?  I really do not
> David> want to include config/svr4.h.
> 
> 	I do not believe that it is productive for FreeBSD to have its
> own, slightly different ABI.

I do not feel FreeBSD has its own "slightly different ABI" any more than
Linux or AIX does.  Linux and FreeBSD, at least, both break ever psABI I
know of by not using the defined name of the dynamic interrupter
specified.

For PowerPC FreeBSD will follow either the ABI or eABI as specified in
"PowerPC Processor ABI Supplement - Sept. 1995". (if you know of a better
PPC psABI, please let me know)

Maybe we should agree on some terms to help the discussion.  Do you
consider what the gabi4.1pdf (System V Application Binary Interface) from
www.sco.com and "PowerPC Processor ABI Supplement - Sept. 1995" describes
to be the ELF or SVR4 ABI?  Both of these uses "SVR4", however wider
usage [here] seems different.  "ELF: From The Programmer's Perspective"
by Hongjiu Lu, says:

    The Executable and Linking Format (ELF) is a binary format originally
    developed and published by UNIX System Laboratories (USL).  It is the
    default binary format for the executable files used by SVR4 and
    Solaris 2.x.

I interrupt this to mean Lu considers the binary format and ABI to be
named "ELF" and SVR4 a consumer of it (having been invented by its
maker).  If you want to call the ABI "SVR4", what term should we use to
describe the Unix system from USL?  As I pointed out in another email,
things like "#define SCCS_DIRECTIVE" and linker command line options are
not specified in any gABI or psABI document I know of and describes an
attribute not of an ABI, but a particular Unix system.

When elfos.h was created from svr4.h, I thought GCC developers in general
had agreed that "svr4" was the Unix system, and "elf" to refer to the
general ABI and object format attributes.  If this is not the case, give
me two terms and lets make the existing elfos.h be svr4.h and the
existing svr4.h to be svr4-implementation.h or what ever two terms you
give me.


> FreeBSD likely will discourage more potential users by being slightly
> incompatible than it gains for any perceived improvement over the
> standard.  This design argument does not seem to be effective with you.

The attributes in the various FreeBSD headers describe attributes of
FreeBSD systems such as the name of our crt.o file is crt1.o, our linker
uses -Bshareable and -Bsymbolic, but not -p, our dynamic linker is
/usr/libexec/ld-elf.so.1, we expect "__PIC__" to be defined if -fPIC was
given on the command line, we don't like DEFAULT_PCC_STRUCT_RETURN, or
WCHAR_UNSIGNED.

Do you consider these to be part of a standard, or just platform
implementation details?  (granted the dynamic linker is address in the
above ABI documents)


> 	"... allows me to do what I need" is not a very compelling
> argument that a patch is correct or should be approved, IMHO.

Why not?  I have a need of greater generality that currently exists.
Because there are an infinite amount of hours for anyone to work on GCC,
people are only going to put time into things that "scratch itches"  You
admitted that you know there are something in rs6000.h that better belong
in aix.h.  Why haven't you moved them there yet?  Because the need isn't
[yet] great enough to spend the time on it.

> From my
> perspective, it seems that you expediently want to solve the symptom of
> your problem and not your problem.

I feel my problem is many of the GCC config headers were written under
the assumption only the vendor's OS is the only OS in existence that runs
on the HW.  Things have gotten better over time, but alpha/alpha.h still
assumes it describes OSF/1.  rs6000/rs6000.h still has assumptions of AIX
in it.  What do you feel is my problem?

> 	Because this patch is small and localized and this discussion no
> longer seems to be productive,

I would like to make it productive.

> I suspect that you will have to return to this issue again (and
> again) and eventually will need to solve it correctly.

Explicitly, what is the correct way to solve it?

-- 
-- David  (obrien@FreeBSD.org)

Re: Conerned about lack of detail in ChangeLog/commit messges

[Richard Kenner]

    This is ancient history now...  

True, but I do want to address one point.

    We can see your attitude in the phrase `I am not aware of any
    legitimate development or tester'. The question is who decides what is
    legitimate?

I don't recall much controversy over that particular issue.  By "legitimate"
I simply meant to distinguish somebody who actually wanted to work on the GCC
project from somebody who was just looking for "the latest and greatest"
without any intent to actually contribute to the project.

Re: Conerned about lack of detail in ChangeLog/commit messges

[Mike Stump]

> Date: Sat, 17 Jun 00 11:53:35 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: martin@loewis.home.cs.tu-berlin.de
> Cc: gcc@gcc.gnu.org

> I have heard many motivations for the start of the egcs project, but
> the one above is new to me: I was not aware of any legitimate
> developer or tester who had problems getting to GCC development
> sources at any point.

This is ancient history now...  but I've heard of it.  There was no
public web page that was widely talked about that told a random tester
(a new tester) that exact instructions for grabbing the source,
exactly where the sources were and so on.  Even if I am wrong on this
point, it proves my point, if I didn't know, how could anyone else
know?  gcc sources are now mirrored on 52 mirrors around the world.
Part of availability, is _high_ availability.  The instructions are
public, and published on a public web site.  This is also rather new.

We can see your attitude in the phrase `I am not aware of any
legitimate development or tester'. The question is who decides what is
legitimate?

See The Cathedral and the Bazaar,
http://www.tuxedo.org/~esr/writings/cathedral-bazaar , for a far more
in-depth treatment of the subject.

One last parting shot, remember, perception isn't your perception, but
rather, everyone else's.

Re: Conerned about lack of detail in ChangeLog/commit messges

[Richard Kenner]

    Of course, it may be that I was not looking hard enough, 

Or that you were looking quietly: a number of people's first involvement
with GCC development started with a posting to a GCC newgroup or bug or
help address.

Re: Conerned about lack of detail in ChangeLog/commit messges

[Richard Kenner]

    One of the major reasons for starting the egcs project was that it was
    so extremely difficult to locate the gcc2 source code - something
    which you are suffering from right now.

At the point in the GCC2 project in question, the problem wasn't difficulty
in getting to the sources (they were available via cvs), but that very few
were interested in doing so.

I have heard many motivations for the start of the egcs project, but the one
above is new to me: I was not aware of any legitimate developer or tester
who had problems getting to GCC development sources at any point.

Re: Conerned about lack of detail in ChangeLog/commit messges

[Martin v. Loewis]

> I have heard many motivations for the start of the egcs project, but the one
> above is new to me: I was not aware of any legitimate developer or tester
> who had problems getting to GCC development sources at any point.

It's probably hard, and may be pointless, to dig in the specific
history today - however I'd like to offer a single data point. I know
that I, personally, found it very hard to even find out how gcc is
being maintained all those years. I had been looking a number of times
since '95, and really all I could find were bug reporting addresses -
these were also recommended for submitting patches. Of course, it may
be that I was not looking hard enough, but I definitely got the
impression that gcc was being developed behind closed doors.

Regards,
Martin

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

The USER_H issue

[Marc Espie]

In article < 564.937826241@upchuck.cygnus.com > you write:
>  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.

I'm sorry, but you keep saying overriding USER_H is wrong, even for
distributors, and I keep telling you that we will end up with two distinct
sets of headers, one for the system proper, and another `special' one for
gcc.

As far as the OpenBSD project is concerned, this is more efficient for us
to rely on our own headers, and tweak the system installation so that those
get used and debugged, instead of having two separate compilers with distinct
sets of bugs...

Please do tell me what's in it for us to remove the USER_H overrides.
I understand that this means simpler maintenance for the gcc project, but
it looks like it only has drawbacks for the OpenBSD project as far as
maintenance is concerned: we just get those `generic' headers with hundreds
of tweaks that don't apply to us, we will probably get some hard to debug
interaction bugs at some point.  It really looks simpler and more robust
to just rely on our own headers and make sure those work.

Not to say you can convince me, but you will have to use real, 
logical arguments, something more convincing than 
`overriding USER_H is wrong'.

The USER_H issue

[Marc Espie]

In article < 564.937826241@upchuck.cygnus.com > you write:
>  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.

I'm sorry, but you keep saying overriding USER_H is wrong, even for
distributors, and I keep telling you that we will end up with two distinct
sets of headers, one for the system proper, and another `special' one for
gcc.

As far as the OpenBSD project is concerned, this is more efficient for us
to rely on our own headers, and tweak the system installation so that those
get used and debugged, instead of having two separate compilers with distinct
sets of bugs...

Please do tell me what's in it for us to remove the USER_H overrides.
I understand that this means simpler maintenance for the gcc project, but
it looks like it only has drawbacks for the OpenBSD project as far as
maintenance is concerned: we just get those `generic' headers with hundreds
of tweaks that don't apply to us, we will probably get some hard to debug
interaction bugs at some point.  It really looks simpler and more robust
to just rely on our own headers and make sure those work.

Not to say you can convince me, but you will have to use real, 
logical arguments, something more convincing than 
`overriding USER_H is wrong'.

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: Pending Projects

[Bruce Korb]

Jeffrey A Law wrote:
> As for deleting [float.h and limits.h], let's take that up later.
> We've got enough major projects in progress already ...

Speaking of which, I have that "no_bogosity" thread
in fixinc that I would like to turn on.  I have nailed
all the blockages to removing the silly grandfather
process (if you remember it), and have added support
for writing C routines for testing and applying fixes.
This is very useful for the "//" elimination fix.  :-)
In a couple of weeks, I would  like to do the following:

1.  Replace gcc/fixincludes with the current version
    of gcc/fixinc/inclhack.sh

2.  Remove the old-method commentary from gcc/Makefile.in

3.  Merge the no_bogosity path into the main line

It features the following:

a)  *Three* binaries are produced
    - fixincl (as today, but with specially coded fixes
               and fix application tests - and no
               grandfather process)
    - fixtests - run from within the new inclhack.sh
               takes two arguments: a file name and test name
    - fixfixes - takes *one* argument: a fix name
               processes stdin to stdout

b)  named tests and fixes can be added as C code
    to fixtests.c and fixfixes.c, respectively.
    Both are included in the fixincl binary.

c)  Replacement text fixes simplify the "wrapper" method.
    (I.e., the file is never massaged.  The text is
    simply written out.)

Re: Pending Projects

[Bruce Korb]

Jeffrey A Law wrote:
> As for deleting [float.h and limits.h], let's take that up later.
> We've got enough major projects in progress already ...

Speaking of which, I have that "no_bogosity" thread
in fixinc that I would like to turn on.  I have nailed
all the blockages to removing the silly grandfather
process (if you remember it), and have added support
for writing C routines for testing and applying fixes.
This is very useful for the "//" elimination fix.  :-)
In a couple of weeks, I would  like to do the following:

1.  Replace gcc/fixincludes with the current version
    of gcc/fixinc/inclhack.sh

2.  Remove the old-method commentary from gcc/Makefile.in

3.  Merge the no_bogosity path into the main line

It features the following:

a)  *Three* binaries are produced
    - fixincl (as today, but with specially coded fixes
               and fix application tests - and no
               grandfather process)
    - fixtests - run from within the new inclhack.sh
               takes two arguments: a file name and test name
    - fixfixes - takes *one* argument: a fix name
               processes stdin to stdout

b)  named tests and fixes can be added as C code
    to fixtests.c and fixfixes.c, respectively.
    Both are included in the fixincl binary.

c)  Replacement text fixes simplify the "wrapper" method.
    (I.e., the file is never massaged.  The text is
    simply written out.)

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!