Re: Convert 3.2 sources to ISO C90

Re: Convert 3.2 sources to ISO C90

[Robert Dewar]

>  In message <20020607000157.3D8AEF2D83@nile.gnat.com>, Robert Dewar writes:
>  > I don't see that. We had no problem building the necessary cross compiler
>  > to move GNAT to HPUX, and the point is that only one person has to do this.
>  > Those following can simply download the bootstrap compiler.
> So, where did you host the cross compiler?  If it was anything other than
> hpux, how did you assemble and link binaries given there is no cross
> assembler or cross linker support for hpux?
> 
> jeff

I am not sure of the answer to this. It was a while ago and was
routine in the sense that whoever was doing it did not have
any difficulty doing it. I will see if I can track down the 
details.

Re: Convert 3.2 sources to ISO C90

[Arnaud Charlet]

> So, where did you host the cross compiler?  If it was anything other than
> hpux, how did you assemble and link binaries given there is no cross
> assembler or cross linker support for hpux?

Actually we didn't even had to go to the trouble of cross compiling,
since the compatibility between 10.20 and 11.00 is not as bad as you
suggested: we installed a GNAT/GCC 2.8.1 binary built on 10.20, which
worked as is under HP UX 11.00.

Yes, the C compiler under HP UX 11.00 was shaky, but was actually
good enough to bootstrap GCC itself with no trouble, so we had no more trouble
to switch GNAT from HP-UX 10.20 to 11.00 than we had to switch from
Solaris 2.5.1 to Solaris 8 (which also didn't require anything special).

Arno

Re: Convert 3.2 sources to ISO C90

[Nathanael Nerode]

On Fri, Jun 07, 2002 at 10:57:10AM +0100, Richard Sandiford wrote:
> Nathanael Nerode <neroden@doctormoo.dyndns.org> writes:
> > Just allowing ordinary ISO prototypes, and defining function
> > arguments ISO-style, would add a lot of readability.  There's a *reason*
> > ANSI choose to do things the way they did; it's *inherently* more
> > readable than the K&R syntax,
> 
> _Inherently_ more readable?  It's a personal thing as much as any other.
> Michael Matz has already said he finds the K&R style more readable, and
> I have to say I do too.  I realise we're outnumbered, though.  ;)

My main complaint with K&R style is that the declarations of the
(types of the) parameters are too similar to the declarations of local
variables.  Well, actually, they're identical, I think. :-)  Great for
obfustication.  It makes function signatures potentially tricky to find 
(since parameters can have their types specified in funny orders),
as opposed to self-evident.  Admittedly, good stylistic pratcice avoids
this.

Personally I like a formatting style for function parameters which gives
each parameter its own line within the parentheses.  I then tend to add 
a comment up top with a typical invocation, so you can see what it
looks like without all those types... by this point I've
duplicated many of the virtues of the K&R style.  Hmm.  ;-)

--Nathanael

Re: Convert 3.2 sources to ISO C90

[Joe Buck]

> > So, where did you host the cross compiler?  If it was anything other than
> > hpux, how did you assemble and link binaries given there is no cross
> > assembler or cross linker support for hpux?

Mike Stump writes:
> One can cross the assembler and ld without much trouble.  One just
> does:
> 
> #!/bin/sh
> # copy files to remote machine
> rsh hp_machine /bin/as $@
> # copy files from remote machine

With common NFS mounts, you don't even need the copying, though you do
need to set the correct current directory (rsh will start the process
in the user's home directory by default).

Re: Convert 3.2 sources to ISO C90

[mike stump]

> To: dewar@gnat.com (Robert Dewar)
> cc: Joe.Buck@synopsys.com, gcc@gcc.gnu.org, rra@stanford.edu
> From: law@redhat.com
> Date: Fri, 07 Jun 2002 14:08:35 -0600

>  In message <20020607000157.3D8AEF2D83@nile.gnat.com>, Robert Dewar writes:
>  > I don't see that. We had no problem building the necessary cross compiler
>  > to move GNAT to HPUX, and the point is that only one person has to do this.
>  > Those following can simply download the bootstrap compiler.
> So, where did you host the cross compiler?  If it was anything other than
> hpux, how did you assemble and link binaries given there is no cross
> assembler or cross linker support for hpux?

One can cross the assembler and ld without much trouble.  One just
does:

#!/bin/sh
# copy files to remote machine
rsh hp_machine /bin/as $@
# copy files from remote machine

I've done this before, not too bad.  Grabbing a binary is far easier
though.

Re: Convert 3.2 sources to ISO C90

[law]

 In message <20020607000157.3D8AEF2D83@nile.gnat.com>, Robert Dewar writes:
 > I don't see that. We had no problem building the necessary cross compiler
 > to move GNAT to HPUX, and the point is that only one person has to do this.
 > Those following can simply download the bootstrap compiler.
So, where did you host the cross compiler?  If it was anything other than
hpux, how did you assemble and link binaries given there is no cross
assembler or cross linker support for hpux?

jeff

Re: Convert 3.2 sources to ISO C90

[Gareth Pearce]

Just a lowly outsiders comment ... but which would be likely to come first,
hp improving ansi support in bundled compiler
or gcc 3.1 source being unavailable?

(I realise theres more to it then just that - but...)

Regards,
Gareth

_________________________________________________________________
Join the worldÂ’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

Re: Convert 3.2 sources to ISO C90

[Mark Mitchell]

> I for one agree with you, for what my opinion is worth.

I agree as well.

The Steering Committee is now actively debating Stan's proposal, and I
would expect that there will be a resolution relatively shortly.

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

Re: Convert 3.2 sources to ISO C90

[Robert Dewar]

<<ie, let's pretend we made this change for GCC 3.0 -- then there would be no way
for folks on hpux11 to easily bootstrap.  Why?  Because 2.95 didn't support
hpux11 and the compiler that comes with hpux11 is non-ANSI and would have
choked.  The only way to bootstrap would be via cross compilation -- but
you don't have cross-assembler or cross-linker support for HPUX targets or
by bludgeoning 2.95 source so that it worked on hpux11 -- something *I*
know how to do simply because I'm intimately familiar the internals of hpux
and how they affect GCC but 99.9% of the world does not know how to do.
Effectively we would have made GCC 3.0 unusable for hpux11 for the overwhelming
majority of developers because there would be no reasonable way to get the
compiler built.
>>

I don't see that. We had no problem building the necessary cross compiler
to move GNAT to HPUX, and the point is that only one person has to do this.
Those following can simply download the bootstrap compiler.

Re: Convert 3.2 sources to ISO C90

[Joe Buck]

> The big deal is that binaries are typically nowhere near as portable on
> HPs as they are on Linux, Solaris, etc and there is no cross toolchain
> support for HPs due to a lack of a cross linker or cross assembler.

But should this be our problem or HP's?  If it's that much of a pain,
maybe we should ask them to solve it for us.

Re: Convert 3.2 sources to ISO C90

[law]

In message <20020606222243.56F98F2D54@nile.gnat.com>, Robert Dewar writes:
 > <<Is having prototypes so important that we're going to make it impossible t
 > o
 > bootstrap GCC on HPs using the native compiler?
 > >>
 > 
 > I would say yes. After all, what we are talking about here in practice is
 > that people have to import a gcc binary to build from sources. What's the
 > big deal? 
The big deal is that binaries are typically nowhere near as portable on
HPs as they are on Linux, Solaris, etc and there is no cross toolchain
support for HPs due to a lack of a cross linker or cross assembler.

jeff

Re: Convert 3.2 sources to ISO C90

[Robert Dewar]

>>But the Byzantine method of declaring functions stinks.

The interesting thing is that those steeped in gcc land actually get to
the point where they like this odd style. I know Richard insisted on
using the nasty unreadable PROTO stuff in gigi (the GNAT interface to the
backend) for example :-)

Re: Convert 3.2 sources to ISO C90

[Robert Dewar]

<This, for me, is an alarming trend. I can understand needing a gnat
compiler to bootstrap ada (though unpleasant that might be). I'm worried
about needing gcc 3.1 to bootstrap gcc 3.2 properly. As long as it only
affects sublanguages, that's mostly fine (though making full support for
ada on new platforms might be painful), but deliberately removing bootstrap
>

All it takes is one person somehwere to do the cross-port, and we have found
in practice for GNAT that the need to do cross-ports has not significantly
impeded the spread of GNAT to various architectures such as the Amiga, MS/DOS,
Nextstep (all ports done by volunteers). 

Now to be fair, there is a difference. To port GNAT, you have to port the
runtime in general, and the tasking in particular, not to mention the tools
(e.g. get task switching to work properly in gdb). In practice the raw step
of getting basic non-tasking GNAT working is pretty trivial compared to the
effort of a full port anyway, and is certainly not the painful part, so the
gain of avoiding this in the case of GNAT would be negligible.

Now for C, this issue of the runtime is much less the case, although there
is still likely to be work in the toolset (gcov, gdb, the binutils in general
etc, and if the target has an idiosyncratic debugging info format, then of
course that effort may be much larger).

I understand historically the value of ensuring that gcc bootstraps with
any old C compiler around, but I do think that the cost (which is to
generate a very odd style in the sources, and to have to write in an
ill-defined subset of C) is significant.

Re: Convert 3.2 sources to ISO C90

[Robert Dewar]

<<Is having prototypes so important that we're going to make it impossible to
bootstrap GCC on HPs using the native compiler?
>>

I would say yes. After all, what we are talking about here in practice is
that people have to import a gcc binary to build from sources. What's the
big deal? 

Re: Convert 3.2 sources to ISO C90

[Michael Matz]

Hi,

On Thu, 6 Jun 2002 law@redhat.com wrote:

> Oh please.  The stuff we're talking about is trivial -- don't use
> prototypes.  Jesus.

FWIW.  I agree with Jeff here.  Not because of knowing all facts, though:
So, maybe someone can tell me, what exactly would be done to make gcc ISO
compatible (I usually only try to program in a way "feeling traditional",
and additionally fix warnings from gcc).  _Except_ the obvious prototypes
thingies.  I for one even find it easier (or at least more aesthetic) to
read function definitions in K&R style.  The need for explicit prototypes
(even with PARAMS()) doesn't disturb me much.  I can run gcc bootstrap in
the default config, fix all warnings in the usual style, and be done with
it.  This alone is absolutely no reason to change all of the source of
gcc.  Prototypes are such a trivial matter I wouldn't even care to
discuss.  They don't clutter up readability.  What else needs to be done
with K&R?  Probably enum's and int promotions?  Anyway I would think it's
wasted energy to convert gcc to ISO meaning basically it can't be build
with HP-UX, without any observable gain (at least for me, maybe someone
can explain the gain to me).

Note also, that it's not about HP-UX especially; I would find changes
dubious anyway if they reduce usability, without any comparable gain
(and I don't think, that questionable improvements to readability (to
whose existance I even disagree, which supports the questionability) are
enough of a gain to be comparative to buildability).


Ciao,
Michael.

Re: Convert 3.2 sources to ISO C90

[Robert Dewar]

 > Or are they effectively going to hold up this "progress" in GCC hostage
 > forever?

Actually it seems to me that a company that does not provide its proprietary
compiler technology "by default" helps GCC, since it allows GCC to compete
on a more even playing field :-)

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
> In message <3CFF9A26.8E139A96@apple.com>, Stan Shebs writes:
>  > Now I'm completely confused.  Your first sentence says you managed to
>  > build (GCC presumably) with bundled compiler + extended ansi behavior,
> No, I was strictly referring to the unbundled compiler.  Never in that message
> did I say *ANYTHING* about the bundled compiler.
> 
> It would help a lot if you took the time to read the message carefully.

Sorry, I reread your message a number of times, but this still
looks like you making a reference to the bundled compiler, starred
and uppercased to make sure that dumb ol' Stan saw it:

> [...]  I've managed to build with the *BUNDLED*
> compiler using a variety of flags to get extended ansi behavior.

Sorry to be both dense and persistent about all this, but the whole
K&R requirement for GCC seems to rest on what HP's various compilers
are and are not capable of doing.  Since I'm regularly in the position
of explaining the K&R requirement both to astonished Apple management
and incredulous new hires, it's helpful to have the precise facts of
the situation.

Stan

Re: Convert 3.2 sources to ISO C90

[John David Anglin]

> Do you mean that "extended ansi behavior" is required to compile GCC
> in its current state?

For 32-bit, the bundled HP compiler is sufficient.  For 64-bit, the
unbundled compiler is currently required.  The exact cause of the
problem in building a 64-bit target with the bundled compiler
hasn't been fully debugged although I think it has to do with using
enums as array indexes.

I'm not against binaries and they are currently more or less necessary
to bootstrap with ada.  I don't think anybody has built ada for a
64-bit hpux11 target because of the complex bootstrap issues.

Personally, I feel that not a lot will be gained by converting.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Convert 3.2 sources to ISO C90

[law]

 In message <3CFFA0BD.896F4E02@apple.com>, Stan Shebs writes:
 > Portability refers to architecture, not compilability by random
 > vendor compilers.  For instance, we can't bootstrap GCC on Windows
 > by using VC++, and it's a good thing let me tell you - we victimized
 > GDB in that way years ago, and there was much huzzah-ing when we
 > finally got rid of all that crud.  I once did horrible things to GCC
 > ca 1989 to get Mac MPW C to compile it, and I can assure you that
 > you're very glad it never contaminated FSF GCC.
I don't disagree at all about this stuff.  But what you're trying to do
is take code which currently works with a class of compilers and
break it.  Effectively saying "I don't care about you anymore".  And
that IMHO is a huge mistake.

 > Perhaps it is going too far.  But GCC is the working compiler upon
 > which many of us depend for our livelihoods, and it's become an old
 > body of source code.  It was only a couple of years ago that we started
 > considering the deletion of obsolete configurations for instance;
 > before that it was like every file was sacred, even if it was actively
 > misleading.  So it's important to question every bit of the status
 > quo, and to make sure that the code doesn't fossilize because people
 > are too afraid or too comfortable to update it.
Actually, I've been recommending we drop platforms for a long time
now.  But only those platforms which are dead.  HPUX with the bundled
compiler is far from a dead platform.

jeff

Re: Convert 3.2 sources to ISO C90

[Gabriel Dos Reis]

Marc Espie <espie@nerim.net> writes:

[...]

I wanted to stay out of this discussion, but I can't let the followiing:

| At a guess again, I want tend to say that any actual ISO C feature that
| is not supported by K&R is bound to make the compiler more brittle.

I disagree.  Using the appropriate types to convey the real intent
isn't something I think make the compiler more brittle. However, I saw
in the past that because we wanted to stay with K&R, we can't use much
more expressive types.  That is a pity. 

-- Gaby

Re: Convert 3.2 sources to ISO C90

[Daniel Jacobowitz]

On Thu, Jun 06, 2002 at 10:21:42AM -0700, Stan Shebs wrote:
> law@redhat.com wrote:
> > NO.  Read "unbundled" in my message.  I've managed to build with the *BUNDLED*
> > compiler using a variety of flags to get extended ansi behavior.
> > 
> > The only success I've had with the bundled compiler has been on non-ANSI
> > code.
> 
> Now I'm completely confused.  Your first sentence says you managed to
> build (GCC presumably) with bundled compiler + extended ansi behavior,
> and your second sentence says that the bundled compiler only works on
> non-ANSI code, which sounds like it contradicts your first sentence.
> Do you mean that "extended ansi behavior" is required to compile GCC
> in its current state?
> 
> Stan
> 

On Thu, Jun 06, 2002 at 11:49:58AM -0600, law@redhat.com wrote:
> In message <3CFF9A26.8E139A96@apple.com>, Stan Shebs writes:
>  > Now I'm completely confused.  Your first sentence says you managed to
>  > build (GCC presumably) with bundled compiler + extended ansi behavior,
> No, I was strictly referring to the unbundled compiler.  Never in that message
> did I say *ANYTHING* about the bundled compiler.
> 
> It would help a lot if you took the time to read the message carefully.

Sorry, Jeff; reread your own message.  You dropped an UN inside the
first pair of stars.  I assume you meant *UNBUNDLED* at least.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

Marc Espie wrote:
> 
> > Is HP really so important that we have to hobble GCC for HP's
> > convenience?
> 
> I thought that GCC was supposed to be a portable compiler. Since when did
> this change ?

Portability refers to architecture, not compilability by random
vendor compilers.  For instance, we can't bootstrap GCC on Windows
by using VC++, and it's a good thing let me tell you - we victimized
GDB in that way years ago, and there was much huzzah-ing when we
finally got rid of all that crud.  I once did horrible things to GCC
ca 1989 to get Mac MPW C to compile it, and I can assure you that
you're very glad it never contaminated FSF GCC.

> This, for me, is an alarming trend. I can understand needing a gnat
> compiler to bootstrap ada (though unpleasant that might be). I'm worried
> about needing gcc 3.1 to bootstrap gcc 3.2 properly. As long as it only
> affects sublanguages, that's mostly fine (though making full support for
> ada on new platforms might be painful), but deliberately removing bootstrap
> ability for the base compiler on some existing platforms is something I
> don't quite grasp.

Perhaps it is going too far.  But GCC is the working compiler upon
which many of us depend for our livelihoods, and it's become an old
body of source code.  It was only a couple of years ago that we started
considering the deletion of obsolete configurations for instance;
before that it was like every file was sacred, even if it was actively
misleading.  So it's important to question every bit of the status
quo, and to make sure that the code doesn't fossilize because people
are too afraid or too comfortable to update it.

Stan

Re: Convert 3.2 sources to ISO C90

[law]

In message <3CFF9A26.8E139A96@apple.com>, Stan Shebs writes:
 > Now I'm completely confused.  Your first sentence says you managed to
 > build (GCC presumably) with bundled compiler + extended ansi behavior,
No, I was strictly referring to the unbundled compiler.  Never in that message
did I say *ANYTHING* about the bundled compiler.

It would help a lot if you took the time to read the message carefully.


jeff

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
> In message <3CFF96FE.68B68282@apple.com>, Stan Shebs writes:
>  > law@redhat.com wrote:
>  > >
>  > >  In message <200206061627.g56GRgg20707@duracef.shout.net>, Michael Elizabe
>  > th
>  > > Cha
>  > > stain writes:
>  > >  > On hpux 10.20 and later, hpux cc has an option "-Ae" to enable
>  > >  > Ansi C, specifically including prototypes.
>  > > More correctly -Ae enables "extended ANSI"; -Aa enables strict ANSI.
>  > >
>  > > I've managed to get things to build with the unbundled compiler using -Ae
>                                                   **********
>  > and
>  > > -Aa with various amounts of hackery.  The problem with them is they muck u
>  > p
>  > > the namespace pretty badly and suddenly functions and structures you expec
>  > t
>  > > to find in the include files aren't there anymore and some which you don't
>  > > expect suddenly exist (leading to wonderful problems in some GNU code whic
>  > h
>  > > at least used to blindly assume it should provide a typedef for uint32_t :
>  > (
>  >
>  > Waitaminnit - you're saying you *can* build pure ISO code with the
>  > bundled compiler, and the obstacles are either HP bugs (which you've
>  > said they'll fix) or GCC bugs, which we can fix?
> NO.  Read "unbundled" in my message.  I've managed to build with the *BUNDLED*
> compiler using a variety of flags to get extended ansi behavior.
> 
> The only success I've had with the bundled compiler has been on non-ANSI
> code.

Now I'm completely confused.  Your first sentence says you managed to
build (GCC presumably) with bundled compiler + extended ansi behavior,
and your second sentence says that the bundled compiler only works on
non-ANSI code, which sounds like it contradicts your first sentence.
Do you mean that "extended ansi behavior" is required to compile GCC
in its current state?

Stan

Re: Convert 3.2 sources to ISO C90

[law]

In message <3CFF96FE.68B68282@apple.com>, Stan Shebs writes:
 > law@redhat.com wrote:
 > > 
 > >  In message <200206061627.g56GRgg20707@duracef.shout.net>, Michael Elizabe
 > th
 > > Cha
 > > stain writes:
 > >  > On hpux 10.20 and later, hpux cc has an option "-Ae" to enable
 > >  > Ansi C, specifically including prototypes.
 > > More correctly -Ae enables "extended ANSI"; -Aa enables strict ANSI.
 > > 
 > > I've managed to get things to build with the unbundled compiler using -Ae 
                                                  **********
 > and
 > > -Aa with various amounts of hackery.  The problem with them is they muck u
 > p
 > > the namespace pretty badly and suddenly functions and structures you expec
 > t
 > > to find in the include files aren't there anymore and some which you don't
 > > expect suddenly exist (leading to wonderful problems in some GNU code whic
 > h
 > > at least used to blindly assume it should provide a typedef for uint32_t :
 > (
 > 
 > Waitaminnit - you're saying you *can* build pure ISO code with the
 > bundled compiler, and the obstacles are either HP bugs (which you've
 > said they'll fix) or GCC bugs, which we can fix?
NO.  Read "unbundled" in my message.  I've managed to build with the *BUNDLED*
compiler using a variety of flags to get extended ansi behavior.

The only success I've had with the bundled compiler has been on non-ANSI
code.

jeff

Re: Convert 3.2 sources to ISO C90

[Neil Booth]

Marc Espie wrote:-

> I still have some big troubles understanding what's the point in
> moving gcc sources to ISO-C ?

Simplification of config/ gunk because we can concatenate strings?
Come on, you're always complaining about GCC and its maintainability,
you should be supporting this.

Neil.

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
>  In message <200206061627.g56GRgg20707@duracef.shout.net>, Michael Elizabeth
> Cha
> stain writes:
>  > On hpux 10.20 and later, hpux cc has an option "-Ae" to enable
>  > Ansi C, specifically including prototypes.
> More correctly -Ae enables "extended ANSI"; -Aa enables strict ANSI.
> 
> I've managed to get things to build with the unbundled compiler using -Ae and
> -Aa with various amounts of hackery.  The problem with them is they muck up
> the namespace pretty badly and suddenly functions and structures you expect
> to find in the include files aren't there anymore and some which you don't
> expect suddenly exist (leading to wonderful problems in some GNU code which
> at least used to blindly assume it should provide a typedef for uint32_t :(

Waitaminnit - you're saying you *can* build pure ISO code with the
bundled compiler, and the obstacles are either HP bugs (which you've
said they'll fix) or GCC bugs, which we can fix?

Stan

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
>  In message <3CFF8DC8.31ED5081@apple.com>, Stan Shebs writes:
>  > But I don't have one, nor do most GCC developers.  We basically
>  > have to rely on the handful of HP maintainers to be the oracles
>  > of whether GCC is properly K&R compatible.
> Oh please.  The stuff we're talking about is trivial -- don't use
> prototypes.  Jesus.

Or anything else in ISO C, like string concatenation.

>  > OK, so let me get this straight - GCC has to have K&R compat because
>  > Red Hat has customers who are too stingy to spring for acc, but who must
>  > have spent lots of money on a support contract if they're getting onsite
>  > support.
> Get real.  Why should anyone (Red Hat customer or not) have to purchase the
> unbundled HP compiler to bootstrap GCC.  The whole point behind that
> was to provide a real world example of the kinds of problems we're going to
> run into if you start ANSI-ifying GCC.

How do people bootstrap on Solaris?  They buy a compiler, or use
a binary package.  How do people get started on Windows?  They cross
compile, or use a binary package.  HP is the one oddball here.

Stan

Re: Convert 3.2 sources to ISO C90

[Nathanael Nerode]

Stan Shebs said:
> That code would be more readable if you didn't have to have all
> the PARAMS and the VA_FIXEDARGS and the like, eh?
Law said:
> That stuff is pretty trivial.  Do you think the really affect the
> readablity of the code that much?

I say, YES.  They affect the readablity of the code a LOT.

Just allowing ordinary ISO prototypes, and defining function
arguments ISO-style, would add a lot of readability.  There's a *reason*
ANSI choose to do things the way they did; it's *inherently* more
readable than the K&R syntax, let alone the bizarre double syntax GCC
uses.

This doesn't even necessarily mean totally losing K&R compilability,
since we can always tell people to run ansi2knr. :-P

Most of the other rules regarding  K&R compatibility in C proper (no
unary +, no 'signed', have to use 'PTR', must cast enums to ints, etc.)
do not really impede readability.  The different integer promotion
rules are irritating, but encourage people to write their promotions
explicitly, which can be good.  The macro concatenation and
stringification rules actually improve readability in some cases.

But the Byzantine method of declaring functions stinks.

--Nathanael

Re: Convert 3.2 sources to ISO C90

[law]

 In message <200206061627.g56GRgg20707@duracef.shout.net>, Michael Elizabeth 
Cha
stain writes:
 > On hpux 10.20 and later, hpux cc has an option "-Ae" to enable
 > Ansi C, specifically including prototypes.
More correctly -Ae enables "extended ANSI"; -Aa enables strict ANSI.  

I've managed to get things to build with the unbundled compiler using -Ae and
-Aa with various amounts of hackery.  The problem with them is they muck up
the namespace pretty badly and suddenly functions and structures you expect
to find in the include files aren't there anymore and some which you don't
expect suddenly exist (leading to wonderful problems in some GNU code which
at least used to blindly assume it should provide a typedef for uint32_t :(

 > gdb's configure script has a section which looks for "-Ae" and enables it.
 > But there are some configury problems with passing this down from the
 > top layer to lower layers.  The recommended way to build on
 > native hppa2.0-hp-hpux10.20 is:
 > 
 >   'CC=cc -Ae' ./configure
 > 
 > Maybe someone with access to an hp machine could play with this.
 > Try downloading gdb 5.2 and look in "gdb/configure" and "gdb/PROBLEMS"
 > for more info. 
:-)  The configure code in gdb was broken last I looked (Nov 2001) in repsect
to how it deals with -Aa/-Ae. if I recall the autoconf folks told me they had
fixed those problems.  There's a thread (and a todo on my list) to get this
code fixed.  It just hasn't bubbled back up to the top of my list.


jeff

Re: Convert 3.2 sources to ISO C90

[Marc Espie]

On Thu, Jun 06, 2002 at 09:28:56AM -0700, Stan Shebs wrote:
> law@redhat.com wrote:
> > 
> >  In message <3CFF5E10.3D440568@apple.com>, Stan Shebs writes:
> >  > That code would be more readable if you didn't have to have all
> >  > the PARAMS and the VA_FIXEDARGS and the like, eh?
> > That stuff is pretty trivial.  Do you think the really affect the
> > readability of the code that much?
> 
> Does a 1% improvement in compiler codegen matter that much?  Not
> by itself.  You can make the same argument for any style point -
> "does putting a space before parens improve the readability of the
> code that much?".

Actually, I personally think that those spaces *degrade* readability,
but, hey, that's me.

> >  > A couple folks have pointed out that K&R C is not well-specified
> >  > either, and indeed all the compilers from the K&R era had slightly
> >  > different behavior.  Since probably nobody bootstraps on SunOS etc
> >  > anymore, the only thing we really know about GCC's K&R compat is
> >  > that it can be built with HP's bundled compiler sometimes.  Not
> >  > a very solid basis on which to write your code!
> > HP's traditional compiler has always been a good test of avoiding
> > ANSI features.
> 
> But I don't have one, nor do most GCC developers.  We basically
> have to rely on the handful of HP maintainers to be the oracles
> of whether GCC is properly K&R compatible.

And pray tell, how is that a problem, since those people are also the ones
who ARE fixing those K&R compatibility issues ?


> What are you going to do when GCC sources change in some way that
> triggers a fatal bug in HP's bundled compiler?  Are we all going to
> be required to know how to code around that bug?
> 
> Is HP really so important that we have to hobble GCC for HP's
> convenience?

I thought that GCC was supposed to be a portable compiler. Since when did
this change ?

This, for me, is an alarming trend. I can understand needing a gnat
compiler to bootstrap ada (though unpleasant that might be). I'm worried
about needing gcc 3.1 to bootstrap gcc 3.2 properly. As long as it only
affects sublanguages, that's mostly fine (though making full support for
ada on new platforms might be painful), but deliberately removing bootstrap
ability for the base compiler on some existing platforms is something I
don't quite grasp.

Yep, even with ansi2knr. Yet another tool that I trust about as far as
libtool or automake...

Re: Convert 3.2 sources to ISO C90

[law]

 In message <3CFF8DC8.31ED5081@apple.com>, Stan Shebs writes:
 > But I don't have one, nor do most GCC developers.  We basically
 > have to rely on the handful of HP maintainers to be the oracles
 > of whether GCC is properly K&R compatible.
Oh please.  The stuff we're talking about is trivial -- don't use
prototypes.  Jesus.



 > OK, so let me get this straight - GCC has to have K&R compat because
 > Red Hat has customers who are too stingy to spring for acc, but who must
 > have spent lots of money on a support contract if they're getting onsite
 > support.
Get real.  Why should anyone (Red Hat customer or not) have to purchase the
unbundled HP compiler to bootstrap GCC.  The whole point behind that
was to provide a real world example of the kinds of problems we're going to
run into if you start ANSI-ifying GCC.

 > What are you going to do when GCC sources change in some way that
 > triggers a fatal bug in HP's bundled compiler?  Are we all going to
 > be required to know how to code around that bug?
We'll get HP to fix the bug.  Been there, done that.  They're more than happy
to fix bugs in their compiler proper.

 > Is HP really so important that we have to hobble GCC for HP's
 > convenience?
Is having prototypes so important that we're going to make it impossible to
bootstrap GCC on HPs using the native compiler?

jeff

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
>  In message <3CFF5E10.3D440568@apple.com>, Stan Shebs writes:
>  > That code would be more readable if you didn't have to have all
>  > the PARAMS and the VA_FIXEDARGS and the like, eh?
> That stuff is pretty trivial.  Do you think the really affect the
> readability of the code that much?

Does a 1% improvement in compiler codegen matter that much?  Not
by itself.  You can make the same argument for any style point -
"does putting a space before parens improve the readability of the
code that much?".

>  > A couple folks have pointed out that K&R C is not well-specified
>  > either, and indeed all the compilers from the K&R era had slightly
>  > different behavior.  Since probably nobody bootstraps on SunOS etc
>  > anymore, the only thing we really know about GCC's K&R compat is
>  > that it can be built with HP's bundled compiler sometimes.  Not
>  > a very solid basis on which to write your code!
> HP's traditional compiler has always been a good test of avoiding
> ANSI features.

But I don't have one, nor do most GCC developers.  We basically
have to rely on the handful of HP maintainers to be the oracles
of whether GCC is properly K&R compatible.

>  > Again, a minor issue, and I wouldn't even have brought it up if
>  > I didn't think that the time and complexity savings justified the
>  > small effort of making the transition.
> I disagree strongly.  It wasn't that long ago I was on-site with a customer
> that had applied a patch from HP which resulted in their copy of GCC being
> utterly useless.  In fact, the HP patch made any existing GCC binary from
> anywhere utterly useless.   This particular customer didn't have the
> unbundled compiler from HP.  Luckily I was able to identify the problems
> the HP patch caused, fix the source for GCC, then bootstrap it using HP's
> bundled compiler.  If we had ANSI-ified the sources, then we would have been
> hosed worse than I care to imagine.

OK, so let me get this straight - GCC has to have K&R compat because
Red Hat has customers who are too stingy to spring for acc, but who must
have spent lots of money on a support contract if they're getting onsite
support.

What are you going to do when GCC sources change in some way that
triggers a fatal bug in HP's bundled compiler?  Are we all going to
be required to know how to code around that bug?

Is HP really so important that we have to hobble GCC for HP's
convenience?

Stan

Re: Convert 3.2 sources to ISO C90

[Michael Elizabeth Chastain]

I'm a gdb guy, not a gcc guy, and I don't have direct access to an hpux
machine.  So take this with a grain of salt.

On hpux 10.20 and later, hpux cc has an option "-Ae" to enable
Ansi C, specifically including prototypes.

gdb's configure script has a section which looks for "-Ae" and enables it.
But there are some configury problems with passing this down from the
top layer to lower layers.  The recommended way to build on
native hppa2.0-hp-hpux10.20 is:

  'CC=cc -Ae' ./configure

Maybe someone with access to an hp machine could play with this.
Try downloading gdb 5.2 and look in "gdb/configure" and "gdb/PROBLEMS"
for more info. 

This may enable gcc to use a lot more Ansi C features (including
prototypes) and still bootstrap using the vendor compiler, at least on
hpux 10.20 and later.  I don't know the hp world enough to say whether
people still use hpux older than 10.20.

I agree with Jeff Law that it's important to keep gcc bootstrappable
with the vendor compiler.

My two cents,

Michael C

Re: Convert 3.2 sources to ISO C90

[Daniel Berlin]

> 
>  > Again, a minor issue, and I wouldn't even have brought it up if
>  > I didn't think that the time and complexity savings justified the
>  > small effort of making the transition.
> I disagree strongly.  It wasn't that long ago I was on-site with a customer
> that had applied a patch from HP which resulted in their copy of GCC being
> utterly useless.  In fact, the HP patch made any existing GCC binary from
> anywhere utterly useless.   This particular customer didn't have the
> unbundled compiler from HP.  Luckily I was able to identify the problems
> the HP patch caused, fix the source for GCC, then bootstrap it using HP's
> bundled compiler.  If we had ANSI-ified the sources, then we would have been
> hosed worse than I care to imagine.

Yes, so hosed you'd have to run ansi2knr (included by automake, and in 
fact, if we used automakeified makefiles, it could be run automatically 
for us when necessary) over the files.

BFD.
--Dan

Re: Convert 3.2 sources to ISO C90

[law]

 In message <3CFF5E10.3D440568@apple.com>, Stan Shebs writes:
 > That code would be more readable if you didn't have to have all
 > the PARAMS and the VA_FIXEDARGS and the like, eh?
That stuff is pretty trivial.  Do you think the really affect the
readability of the code that much?


 > But yes, this is a minor issue, just as removing obsolete configs
 > is a minor issue.  To me the main problem with the K&R requirement
 > is that it adds a bunch of programming rules that you can't test for
 > without having an actual K&R compiler (-traditional not being a
 > perfect emulation).  This is very much like the obsolete config
 > situation, where infrastructure changes are easier if there aren't
 > a lot of obsolete broken configs to change.
I don't consider this anything like obsolete configurations.  Obsolete
configurations take a quite a bit more ongoing maintenance as we update
things (particularly moving to a more target-vector like approach) and
old configurations take quite a bit more thought as we change how the
optimizer works.  For example -- who really understands how minor tweaks
to the optimizer is going to affect the convex, or the pyramid, or the
mn102?

 > A couple folks have pointed out that K&R C is not well-specified
 > either, and indeed all the compilers from the K&R era had slightly
 > different behavior.  Since probably nobody bootstraps on SunOS etc
 > anymore, the only thing we really know about GCC's K&R compat is
 > that it can be built with HP's bundled compiler sometimes.  Not
 > a very solid basis on which to write your code!
HP's traditional compiler has always been a good test of avoiding
ANSI features.

 > Again, a minor issue, and I wouldn't even have brought it up if
 > I didn't think that the time and complexity savings justified the
 > small effort of making the transition.
I disagree strongly.  It wasn't that long ago I was on-site with a customer
that had applied a patch from HP which resulted in their copy of GCC being
utterly useless.  In fact, the HP patch made any existing GCC binary from
anywhere utterly useless.   This particular customer didn't have the
unbundled compiler from HP.  Luckily I was able to identify the problems
the HP patch caused, fix the source for GCC, then bootstrap it using HP's
bundled compiler.  If we had ANSI-ified the sources, then we would have been
hosed worse than I care to imagine.


 > > Plust, it's going to divert some people's energy (Jeff) into making
 > > HP-UX work still (and loads of bug-reports I am sure).
 > 
 > It's not at all clear to me that Jeff would have to do anything
 > because of the switch.  In fact, what I've heard so far is that
 > the status quo involves extra work for each release, clearing
 > out ISOisms in the code.
It would certainly require more work for me and cause folks building GCC
on HPs even more problems than they currently face.

The amount of work to clear out ISOisms is trivial (I know because I do it
pretty regularly).  

jeff

Re: Convert 3.2 sources to ISO C90

[law]

 In message <20020606133333.GA23950@tetto.liafa.jussieu.fr>, Marc Espie writes:
 > Are there really many cases where cleaning up ISOisms has been more
 > than just cleaning up ISOisms, e.g., actually requiring changes to the
 > structure.
The vast majority of these problems are the unintentional introduction of
a prototype.  Fixing them is trivial.

jeff

Re: Convert 3.2 sources to ISO C90

[Marc Espie]

In article <3CFF5E10.3D440568@apple.com> you write:
>Marc Espie wrote:

>> I still have some big troubles understanding what's the point in
>> moving gcc sources to ISO-C ?

>> It's not as if K&R C was such an arcane dialect.  Are there really that
>> many gcc developers that don't know K&R C. Heck, I'm much more confused
>> by the mostly unreadable GNU coding conventions myself.

>That code would be more readable if you didn't have to have all
>the PARAMS and the VA_FIXEDARGS and the like, eh?

Actually, I get much more confused by the extra space before parenthesis,
or the two spaces indent, plus the waste of two indent levels per block.

But I digress...

Re: Convert 3.2 sources to ISO C90

[Marc Espie]

On Thu, Jun 06, 2002 at 06:05:20AM -0700, Stan Shebs wrote:
> It's not at all clear to me that Jeff would have to do anything
> because of the switch.  In fact, what I've heard so far is that
> the status quo involves extra work for each release, clearing
> out ISOisms in the code.

And clearing out ISOisms in the code is something that is done by
people who need it to compile on K&R compilers, is it not ?

So, they have an interest in cleaning that up, don't they ?

At a guess, I'm sure it always goes like that: some of those people
sends along a patch to clean up some ISOism, plus a recommendation that
says `don't do that, it's not K&R'.

Are there really many cases where cleaning up ISOisms has been more
than just cleaning up ISOisms, e.g., actually requiring changes to the
structure.

At a guess again, I want tend to say that any actual ISO C feature that
is not supported by K&R is bound to make the compiler more brittle.
Something we do not want, do we ?

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

Marc Espie wrote:
> 
> I still have some big troubles understanding what's the point in
> moving gcc sources to ISO-C ?
> 
> It's not as if K&R C was such an arcane dialect.  Are there really that
> many gcc developers that don't know K&R C. Heck, I'm much more confused
> by the mostly unreadable GNU coding conventions myself.

That code would be more readable if you didn't have to have all
the PARAMS and the VA_FIXEDARGS and the like, eh?

But yes, this is a minor issue, just as removing obsolete configs
is a minor issue.  To me the main problem with the K&R requirement
is that it adds a bunch of programming rules that you can't test for
without having an actual K&R compiler (-traditional not being a
perfect emulation).  This is very much like the obsolete config
situation, where infrastructure changes are easier if there aren't
a lot of obsolete broken configs to change.

A couple folks have pointed out that K&R C is not well-specified
either, and indeed all the compilers from the K&R era had slightly
different behavior.  Since probably nobody bootstraps on SunOS etc
anymore, the only thing we really know about GCC's K&R compat is
that it can be built with HP's bundled compiler sometimes.  Not
a very solid basis on which to write your code!

Again, a minor issue, and I wouldn't even have brought it up if
I didn't think that the time and complexity savings justified the
small effort of making the transition.

> Plust, it's going to divert some people's energy (Jeff) into making
> HP-UX work still (and loads of bug-reports I am sure).

It's not at all clear to me that Jeff would have to do anything
because of the switch.  In fact, what I've heard so far is that
the status quo involves extra work for each release, clearing
out ISOisms in the code.

Stan

Re: Convert 3.2 sources to ISO C90

[Albert Chin]

On Wed, Jun 05, 2002 at 03:04:12PM -0600, law@redhat.com wrote:
> In message <3CFE7AA9.553C5298@apple.com>, Stan Shebs writes:
>  > Is there some reason not to provide GCC binaries for these HP
>  > users?  Are these people on new or old machines?  Has anybody
>  > talked to HP about hosting the GCC binaries?  Seems like a good
>  > PR move to me; I'm sure HP doesn't want to be publicly known as
>  > the sole reason for GCC using pre-ISO C, doesn't sound like the
>  > sort of company developers would want to support.
> HP has tried to host binaries in the past.  A goodly number of the bug reports
> we get are because they've always messed it up.    We really don't want to
> get into the binary distribution business, particularly on a platform that
> is so, err, "fun" as HPs.

HP provides pre-compiled binaries of GCC for HP-UX 11.00 and 11.00
(11i). They don't offer pre-compiled binaries for HP-UX 10.20 (which
HP will bring EOL in a month or two, if not already).

http://h21007.www2.hp.com/dev/
  
-- 
albert chin (china@thewrittenword.com)

Re: Convert 3.2 sources to ISO C90

[Marc Espie]

I still have some big troubles understanding what's the point in
moving gcc sources to ISO-C ?

It's not as if K&R C was such an arcane dialect.  Are there really that
many gcc developers that don't know K&R C. Heck, I'm much more confused
by the mostly unreadable GNU coding conventions myself.

Plust, it's going to divert some people's energy (Jeff) into making 
HP-UX work still (and loads of bug-reports I am sure).

Could we try to do something useful instead, like regaining some speed
in the compiler ?...

Re: Convert 3.2 sources to ISO C90

[Jan Hubicka]

> law@redhat.com wrote:
> > 
> > [...]  In fact we've received bug reports within
> > the last couple weeks due to folks trying to build on HPs using the bundled
> > compiler and running into cases where ANSI-isms have crept into the sources.
> 
> I think it's very telling that a) the ISOisms are quietly showing
> up over and over, and that b) there is only a small group of HP
> users that ever notice this.

I am one of the HP users, and at least my CC do have -Aa switch that
changes compiler into "pseudo ANSI" mode that compiles new sources.  I
can still use 2.7.0 as my bootstrap compiler.


Honza
> 
> Is there some reason not to provide GCC binaries for these HP
> users?  Are these people on new or old machines?  Has anybody
> talked to HP about hosting the GCC binaries?  Seems like a good
> PR move to me; I'm sure HP doesn't want to be publicly known as
> the sole reason for GCC using pre-ISO C, doesn't sound like the
> sort of company developers would want to support.
> 
> Stan

Re: Convert 3.2 sources to ISO C90

[Geoff Keating]

law@redhat.com writes:

>  In message <20020606045720.GA13668@nevyn.them.org>, Daniel Jacobowitz writes:
>  > Conveniently, I believe Geoff contributed the basis of code to run
>  > fixincludes at install rather than build time last week... Packaging it
>  > up appropriately should just be the matter of an hour or two.
> Yup.  What's even better is the ability to run fixincludes *after* installation
> of the compiler.  Cygnus/Red Hat has had hacks to do this for a long time
> as it didn't make any sense (and was a legal minefield) to distribute
> fixed header files as part of our releases.

The code will work at any time, it just blows away the old fixed
headers and makes new ones.  The user interface is that you run
$prefix/lib/gcc-lib/<target>/<version>/install-tools/mkheaders after
installation or changing headers.  I'm still unsure whether perhaps
there should be something in $prefix/bin (actually, I suspect it
really goes in $prefix/sbin).

I haven't tested it on HPUX, it would be really good to try it and see
if it works (and fix it if not...).  The testcase is to install the
compiler, save the old headers, run it, and check that you get the
same results.

Even more interesting, though, is the reason I did it.  It was necessary to
do this to have a reliable Ada bootstrap compiler.  Now, HPUX may come
with a cc, but it certainly doesn't come with GCC 3.1 Ada (which is
what GCC 3.2 Ada will require for bootstrap, I hear).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Convert 3.2 sources to ISO C90

[Robert Lipe]

> > No, what it really means is that some poor GCC developer gets stuck
> > doing this stuff.  HP certainly isn't going to do it.  So what it
> > really means is that *I* get stuck doing this crap.
>
> But getting back to ISO conversion, HP does have an ISO compiler - it
> just costs money.

In terms of the rocket science involved in the compiler, this is simply
not a problem that's Jeff-worthy.  Solving this problem needs someone
with access to a reasonable compiler and at least remedial shell
scripting abilities that can spin a binary release once in a while.

And if nobody steps forward to place even that much effort on HP-UX,
then can this whole HP-UX data point be optimized away and get back 
to the question of whether GCC can be written in a formally described
language?


RJL

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
> In message <20020605.225401.85393578.davem@redhat.com>, "David S. Miller" write
> s:
>  >    From: law@redhat.com
>  >    Date: Wed, 05 Jun 2002 23:58:11 -0600
>  >
>  >    However, we still have the problem of how do we bootstrap on new versions
>  >    of hpux -- they're notorious for changing more than just the header files
>  > .
>  >    We could easily end up in a situation where the binaries we have simply
>  >    aren't suitable for new versions of hpux, at which point were're rather
>  >    hosed.
>  >
>  > Then they will have to wait until HP provides binaries of GCC-3.X
>  > whichever is the one that supports that new version of HPUX first.
> No, what it really means is that some poor GCC developer gets stuck doing
> this stuff.  HP certainly isn't going to do it.  So what it really means
> is that *I* get stuck doing this crap.

But getting back to ISO conversion, HP does have an ISO compiler - it just
costs money.  Cygnus used to be able to get copies for free because
of contracts - is this no longer the case for Red Hat?  I bet there are
HP people who would be glad to donate acc copies if it meant that GCC
didn't have to be K&R code any longer; how about it all you HPers reading
this list?

It also occurs to me that if volunteers refuse to port to new
versions of HP/UX until HP coughs up an ISO compiler, HP might get
some motivation all of a sudden.  And if they don't, well, who
really wants to go to that much trouble for some random proprietary
OS anyhow?

Stan

Re: Convert 3.2 sources to ISO C90

[law]

In message <20020606060331.GI724@rjlhome.caldera.com>, Robert Lipe writes:
 > law@redhat.com wrote:
 > 
 > > However, we still have the problem of how do we bootstrap on new versions
 > > of hpux -- they're notorious for changing more than just the header files.
 > > We could easily end up in a situation where the binaries we have simply
 > > aren't suitable for new versions of hpux, at which point were're rather
 > > hosed.
 > 
 > How is this different from any other OS that may change under us?  If
 > the OS changes in some horrible way that makes it incompatible with a
 > previous version, someone with a supported compiler (vendor, cross,
 > previous gcc, whatever) has to build it to make it available to the next
 > generation.
I agree it's not any different in theory.  THe problem is HP has consistently
made major changes that have affect the compiler -- enough such that using
old tools to start the bootstrap process hasn't been an option.

jeff

Re: Convert 3.2 sources to ISO C90

[David S. Miller]

   From: Robert Lipe <robertlipe@usa.net>
   Date: Thu, 6 Jun 2002 01:03:31 -0500
   
   How is this different from any other OS that may change under us?  If
   the OS changes in some horrible way that makes it incompatible with a
   previous version, someone with a supported compiler (vendor, cross,
   previous gcc, whatever) has to build it to make it available to the next
   generation.
   
Exactly.

Re: Convert 3.2 sources to ISO C90

[David S. Miller]

   From: law@redhat.com
   Date: Thu, 06 Jun 2002 00:06:11 -0600

   No, what it really means is that some poor GCC developer gets stuck doing
   this stuff.  HP certainly isn't going to do it.  So what it really means
   is that *I* get stuck doing this crap.
   
So we're stuck with K&R because nobody can be found to make GCC
binaries for HP, that is what this all amounts to.
   
   Solaris has been a lot more stable in its ability to run the compiler across
   different revisions if the OS.  In HP-land things haven't ever been that
   stable.  
   
Regardless the sunfreeware.com site is continually making new
binaries available when new versions of GCC are released.

So even if Solaris had the technical problems HPUX does, it
still wouldn't matter.

So again, what you're telling us is that GCC sources should be
stuck with K&R simply because nobody is going to make binary packages
for HP.

This is why I found the whole HP platform argument comical since the
beginning of this thread.

Re: Convert 3.2 sources to ISO C90

[Robert Lipe]

law@redhat.com wrote:

> However, we still have the problem of how do we bootstrap on new versions
> of hpux -- they're notorious for changing more than just the header files.
> We could easily end up in a situation where the binaries we have simply
> aren't suitable for new versions of hpux, at which point were're rather
> hosed.

How is this different from any other OS that may change under us?  If
the OS changes in some horrible way that makes it incompatible with a
previous version, someone with a supported compiler (vendor, cross,
previous gcc, whatever) has to build it to make it available to the next
generation.

Re: Convert 3.2 sources to ISO C90

[law]

In message <20020605.225401.85393578.davem@redhat.com>, "David S. Miller" write
s:
 >    From: law@redhat.com
 >    Date: Wed, 05 Jun 2002 23:58:11 -0600
 >    
 >    However, we still have the problem of how do we bootstrap on new versions
 >    of hpux -- they're notorious for changing more than just the header files
 > .
 >    We could easily end up in a situation where the binaries we have simply
 >    aren't suitable for new versions of hpux, at which point were're rather
 >    hosed.
 > 
 > Then they will have to wait until HP provides binaries of GCC-3.X
 > whichever is the one that supports that new version of HPUX first.
No, what it really means is that some poor GCC developer gets stuck doing
this stuff.  HP certainly isn't going to do it.  So what it really means
is that *I* get stuck doing this crap.


 > I don't see what the problem is.  Solaris has the same issues.
 > There is nothing HP specific about any of the issues you raise.
Solaris has been a lot more stable in its ability to run the compiler across
different revisions if the OS.  In HP-land things haven't ever been that
stable.  

jeff

Re: Convert 3.2 sources to ISO C90

[David S. Miller]

   From: law@redhat.com
   Date: Wed, 05 Jun 2002 23:58:11 -0600
   
   However, we still have the problem of how do we bootstrap on new versions
   of hpux -- they're notorious for changing more than just the header files.
   We could easily end up in a situation where the binaries we have simply
   aren't suitable for new versions of hpux, at which point were're rather
   hosed.

Then they will have to wait until HP provides binaries of GCC-3.X
whichever is the one that supports that new version of HPUX first.

I don't see what the problem is.  Solaris has the same issues.
There is nothing HP specific about any of the issues you raise.

Re: Convert 3.2 sources to ISO C90

[law]

 In message <3CFEF799.B8B63C35@apple.com>, Stan Shebs writes:
 > So it sounds like this would take away one of your concerns about
 > making HP binaries available to people who need something to get
 > started with?  People will be able to use 3.1 now to get started,
 > and then build 3.2 binaries with install-time fixincludes in the
 > future.
It fixes one of them (ability to provide binaries that are likely to 
work across a large number of systems).

However, we still have the problem of how do we bootstrap on new versions
of hpux -- they're notorious for changing more than just the header files.
We could easily end up in a situation where the binaries we have simply
aren't suitable for new versions of hpux, at which point were're rather
hosed.


jeff

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
>  In message <20020606045720.GA13668@nevyn.them.org>, Daniel Jacobowitz writes:
>  > Conveniently, I believe Geoff contributed the basis of code to run
>  > fixincludes at install rather than build time last week... Packaging it
>  > up appropriately should just be the matter of an hour or two.
> Yup.  What's even better is the ability to run fixincludes *after* installation
> of the compiler.  Cygnus/Red Hat has had hacks to do this for a long time
> as it didn't make any sense (and was a legal minefield) to distribute
> fixed header files as part of our releases.
> 
> For example, let's say you built & installed GCC.  Then you installed some
> patch from your vendor which twiddled the include files -- you want to
> get those newly twiddled include files re-scanned and fixed.
> 
> This means that fixincludes would actually be part of the installed set of
> programs so that it could be run later.  Or re-run if the install directory
> is copied from one system to another.

So it sounds like this would take away one of your concerns about
making HP binaries available to people who need something to get
started with?  People will be able to use 3.1 now to get started,
and then build 3.2 binaries with install-time fixincludes in the
future.

Stan

Re: Convert 3.2 sources to ISO C90

[law]

 In message <20020606045720.GA13668@nevyn.them.org>, Daniel Jacobowitz writes:
 > Conveniently, I believe Geoff contributed the basis of code to run
 > fixincludes at install rather than build time last week... Packaging it
 > up appropriately should just be the matter of an hour or two.
Yup.  What's even better is the ability to run fixincludes *after* installation
of the compiler.  Cygnus/Red Hat has had hacks to do this for a long time
as it didn't make any sense (and was a legal minefield) to distribute
fixed header files as part of our releases.

For example, let's say you built & installed GCC.  Then you installed some
patch from your vendor which twiddled the include files -- you want to 
get those newly twiddled include files re-scanned and fixed.

This means that fixincludes would actually be part of the installed set of
programs so that it could be run later.  Or re-run if the install directory
is copied from one system to another.

jeff

Re: Convert 3.2 sources to ISO C90

[David S. Miller]

   From: law@redhat.com
   Date: Wed, 05 Jun 2002 22:54:29 -0600
   
    > This is a problem independent of moving 3.2 away from the
    > K&R requirement.

   Certainly.  If it wasn't for fixincludes it'd be a hell of a lot easier to
   take a compiler built on version of the OS and use it on another.

It sounds like a useful improvement would be to allow
running fixincludes during installation.  People who care
about this (those concerned about HPUX for example) can implement it.
:-)

Re: Convert 3.2 sources to ISO C90

[Robert Lipe]

law@redhat.com wrote:
>  In message <20020605.192105.111716507.davem@redhat.com>, "David S. Miller" 
> writes:
>  >    
>  > So what is sunfreeware.com doing right for Solaris folks that
>  > the people hosting the HP stuff aren't getting right?
> A large part of it is fixincludes.  On Solaris we're able to avoid lots of
> fixed includes via various schemes -- mostly because the Solaris header
> files are pretty close to what GCC needs.  HPUX is a radically different

But this problem has been solved by everybody that's put together a
binary distribution that needs to run on more than one patchlevel of an
OS.  The distribution package provides the basic binaries and libraries
in the package and runs fixincludes as part of the installation process.[1]

This also lets you conveniently skirt the legal issues of distributing
"fixed" versions of vendor headers...

RJL

[1] What hoses users is then when they install an OS upgrade without 
    re-running fixincludes, but that's not the problem at hand.

Re: Convert 3.2 sources to ISO C90

[Daniel Jacobowitz]

On Wed, Jun 05, 2002 at 10:54:29PM -0600, law@redhat.com wrote:
>  In message <20020605.192105.111716507.davem@redhat.com>, "David S. Miller" 
> writes:
>  >    
>  > So what is sunfreeware.com doing right for Solaris folks that
>  > the people hosting the HP stuff aren't getting right?
> A large part of it is fixincludes.  On Solaris we're able to avoid lots of
> fixed includes via various schemes -- mostly because the Solaris header
> files are pretty close to what GCC needs.  HPUX is a radically different
> story unfortunately.
> 
>  > This is a problem independent of moving 3.2 away from the
>  > K&R requirement.
> Certainly.  If it wasn't for fixincludes it'd be a hell of a lot easier to
> take a compiler built on version of the OS and use it on another.

Conveniently, I believe Geoff contributed the basis of code to run
fixincludes at install rather than build time last week... Packaging it
up appropriately should just be the matter of an hour or two.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Convert 3.2 sources to ISO C90

[law]

 In message <20020605.192105.111716507.davem@redhat.com>, "David S. Miller" 
writes:
 >    
 > So what is sunfreeware.com doing right for Solaris folks that
 > the people hosting the HP stuff aren't getting right?
A large part of it is fixincludes.  On Solaris we're able to avoid lots of
fixed includes via various schemes -- mostly because the Solaris header
files are pretty close to what GCC needs.  HPUX is a radically different
story unfortunately.

 > This is a problem independent of moving 3.2 away from the
 > K&R requirement.
Certainly.  If it wasn't for fixincludes it'd be a hell of a lot easier to
take a compiler built on version of the OS and use it on another.

jeff

Re: Convert 3.2 sources to ISO C90

[David S. Miller]

   From: law@redhat.com
   Date: Wed, 05 Jun 2002 20:06:53 -0600

    In message <20020605212205.GT724@rjlhome.caldera.com>, Robert Lipe writes:
    > Whether HP hosts a site of binaries or not shouldn't even be a question.
    > Anybody that cares about HP-UX can put up a binary kit, right?  Two such
    > sites are referenced from gcc.gnu.org.

   True, but those binaries consistently don't work.  The number of bug reports
   I see from folks trying to use them is significant.  
   
So what is sunfreeware.com doing right for Solaris folks that
the people hosting the HP stuff aren't getting right?

This is a problem independent of moving 3.2 away from the
K&R requirement.

Re: Convert 3.2 sources to ISO C90

[law]

 In message <20020605212205.GT724@rjlhome.caldera.com>, Robert Lipe writes:
 > Whether HP hosts a site of binaries or not shouldn't even be a question.
 > Anybody that cares about HP-UX can put up a binary kit, right?  Two such
 > sites are referenced from gcc.gnu.org.
True, but those binaries consistently don't work.  The number of bug reports
I see from folks trying to use them is significant.  

jeff

Re: Convert 3.2 sources to ISO C90

[law]

In message <200206052214.PAA04093@atrus.synopsys.com>, Joe Buck writes:
 > 
 > > Maybe I'm not being sufficiently sympathetic to HP-UX users, but as a
 > > long-time Solaris user, I have to admit that I don't quite understand the
 > > difficulties of downloading a binary version of GCC to use as a bootstrap
 > > compiler.
 > 
 > Even for those organizations who are too paranoid to do this, they can
 > bootstrap an older GCC and use it to build the newer one.
That doesn't always work with new versions of the OS.

ie, let's pretend we made this change for GCC 3.0 -- then there would be no way
for folks on hpux11 to easily bootstrap.  Why?  Because 2.95 didn't support
hpux11 and the compiler that comes with hpux11 is non-ANSI and would have
choked.  The only way to bootstrap would be via cross compilation -- but 
you don't have cross-assembler or cross-linker support for HPUX targets or
by bludgeoning 2.95 source so that it worked on hpux11 -- something *I*
know how to do simply because I'm intimately familiar the internals of hpux
and how they affect GCC but 99.9% of the world does not know how to do.   
Effectively we would have made GCC 3.0 unusable for hpux11 for the overwhelming
majority of developers because there would be no reasonable way to get the
compiler built.


I really think we're taking a step backwards if we go this direction.

jeff

Re: Convert 3.2 sources to ISO C90

[Joe Buck]

> Maybe I'm not being sufficiently sympathetic to HP-UX users, but as a
> long-time Solaris user, I have to admit that I don't quite understand the
> difficulties of downloading a binary version of GCC to use as a bootstrap
> compiler.

Even for those organizations who are too paranoid to do this, they can
bootstrap an older GCC and use it to build the newer one.

Re: Convert 3.2 sources to ISO C90

[Jeff Sturm]

On Wed, 5 Jun 2002 law@redhat.com wrote:
>  In message <20020605210128.GD5421@daikokuya.demon.co.uk>, Neil Booth writes:
>  > Is HP ever going to ship a more modern compiler by default?
> I have no clue.

They could ship GCC if they chose, though it wouldn't help much for
prior releases (is anyone still on 9.x?).

But I don't see how the situation is worse than vendors like Sun, who
don't ship a working cc at all.  Solaris users are used to buying an ISO
compiler or going to sunfreeware.com to get their bootstrap cc.  Likewise
for Windows users, etc.  The GCC project doesn't host binaries for those
platforms either.

HP user gets special consideration because their vendor still ships an
ancient compiler that could bootstrap previous GCC releases?  

> I don't think that converting GCC to ANSI/ISO brings us that much of a
> significant improvement in GCC itself.  So I wouldn't classify this as
> holding GCC progress hostage.

GCC already presents too many obstacles to newcomers, this funny dialect
of C being just one example.

Jeff

Re: Convert 3.2 sources to ISO C90

[Russ Allbery]

law <law@redhat.com> writes:

> Yes, but do we want to lock them out of being able to build GCC?  That
> seems so counter-intuitive as to be silly to me.

> And given that the reports came in nearly immediately after GCC 3.1 was
> released and multiple times I'm not sure I'd call it a "small group".

> I think this would be an amazingly bad thing to do.

Maybe I'm not being sufficiently sympathetic to HP-UX users, but as a
long-time Solaris user, I have to admit that I don't quite understand the
difficulties of downloading a binary version of GCC to use as a bootstrap
compiler.  Everyone who hasn't purchased Sun's commercial compiler has had
to do that to get GCC working for years now.  I've done it, and it's not
particularly hard.  Mildly annoying, sure, but not really that hard.

I guess it's easier on Solaris in that it's usually been possible to use
GCC built on Solaris 7 to bootstrap a build on Solaris 8 and so forth.  If
one has to download a bootstrap compiler after every OS upgrade, it's a
bit more of a hassle.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

David Edelsohn wrote:
> 
> >>>>> Stan Shebs writes:
> 
> Stan> Ironically, I'll bet a large percentage of that group already has
> Stan> GCC on their systems, but configure prefers "cc" over "gcc" (for
> Stan> good reasons I suppose), so it'll find the pre-ISO compiler even if
> Stan> a working GCC is available...
> 
>         Configure prefers "gcc" over "cc".  The reason none of the HP
> testers see the problem is that configure always finds gcc, so they never
> test building with cc which presumably is on their HP/UX system.

You're right.  I actually tested this one on my own machine before
making the claim, because I wasn't sure, but forgot that I have a
makefile fragment that overrides what configure chooses!

Stan

Re: Convert 3.2 sources to ISO C90

[Neil Booth]

Robert Lipe wrote:-

> We've been pretty intolerant about supporting other "broken" vendor
> compilers for years.  The only proposed change in policy is to start
> considering a dead dialect (of a language that's been formally specified
> twice) to be "broken".  K&R has all kinds of rules that just plain
> aren't well known to a generation of programmers these days.  It does
> obscure the code.
> 
> Whether HP hosts a site of binaries or not shouldn't even be a question.
> Anybody that cares about HP-UX can put up a binary kit, right?  Two such
> sites are referenced from gcc.gnu.org.

And as Kelley pointed out, there's always GCC 2.95.x or GCC 3.x.y as a
"bridge compiler" for someone who's genuinely stuck.

Neil.

Re: Convert 3.2 sources to ISO C90

[David Edelsohn]

>>>>> Stan Shebs writes:

Stan> Ironically, I'll bet a large percentage of that group already has
Stan> GCC on their systems, but configure prefers "cc" over "gcc" (for
Stan> good reasons I suppose), so it'll find the pre-ISO compiler even if
Stan> a working GCC is available...

	Configure prefers "gcc" over "cc".  The reason none of the HP
testers see the problem is that configure always finds gcc, so they never
test building with cc which presumably is on their HP/UX system.

	Do the people building gcc not have gcc in their path?

David

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
> In message <3CFE7AA9.553C5298@apple.com>, Stan Shebs writes:
>  > law@redhat.com wrote:
>  > >
>  > > [...]  In fact we've received bug reports within
>  > > the last couple weeks due to folks trying to build on HPs using the bundle
>  > d
>  > > compiler and running into cases where ANSI-isms have crept into the source
>  > s.
>  >
>  > I think it's very telling that a) the ISOisms are quietly showing
>  > up over and over, and that b) there is only a small group of HP
>  > users that ever notice this.
> Yes, but do we want to lock them out of being able to build GCC?  That
> seems so counter-intuitive as to be silly to me.
> 
> And given that the reports came in nearly immediately after GCC 3.1 was
> released and multiple times I'm not sure I'd call it a "small group".

Ironically, I'll bet a large percentage of that group already has
GCC on their systems, but configure prefers "cc" over "gcc" (for
good reasons I suppose), so it'll find the pre-ISO compiler even if
a working GCC is available...

In any case, it sounds like if a single person were to volunteer to
make a 3.1 binary available for HPs, this group would be able to use
that binary rather than try to build their own.  And if they
wanted to build 3.1.1, 3.2, etc binaries later, they could start
bootstrapping from the 3.1 binary, right?

Stan

Re: Convert 3.2 sources to ISO C90

[Kelley Cook]

>In message <3CFE7AA9.553C5298@apple.com>, Stan Shebs writes:
>> law@redhat.com wrote:
>>>
>>> [...]  In fact we've received bug reports within
>>> the last couple weeks due to folks trying to build on HPs using the bundled
>>> compiler and running into cases where ANSI-isms have crept into the sources.
>>
>> I think it's very telling that a) the ISOisms are quietly showing
>> up over and over, and that b) there is only a small group of HP
>> users that ever notice this.
>Yes, but do we want to lock them out of being able to build GCC?  That
>seems so counter-intuitive as to be silly to me.
>
>And given that the reports came in nearly immediately after GCC 3.1 was
>released and multiple times I'm not sure I'd call it a "small group".
>
>I think this would be an amazingly bad thing to do.

As an admin who supports thousands of HP boxes, I disagree.

It is simple to put directions in the HP section such as: "As of GCC 3.2 you
need an ANSI compiler to compile GCC.  As HP does not supply one, please either
download a binary copy of GCC 3.1 or first build GCC 2.95.3 (or 3.1.1 assuming
it works) which works with the old HP compiler and use that to build GCC 3.2."

This, IMO, is MUCH better than what just occurred with GCC 3.1 which didn't
bootstrap on the stock HPUX install because no GCC developer tests with HP's
junky bundled compiler.

My 2¢,
Kelley Cook

Re: Convert 3.2 sources to ISO C90

[Robert Lipe]

Neil Booth wrote:

> Or are [hp] effectively going to hold up this "progress" in GCC hostage
> forever?

We've been pretty intolerant about supporting other "broken" vendor
compilers for years.  The only proposed change in policy is to start
considering a dead dialect (of a language that's been formally specified
twice) to be "broken".  K&R has all kinds of rules that just plain
aren't well known to a generation of programmers these days.  It does
obscure the code.

Whether HP hosts a site of binaries or not shouldn't even be a question.
Anybody that cares about HP-UX can put up a binary kit, right?  Two such
sites are referenced from gcc.gnu.org.

RJL

Re: Convert 3.2 sources to ISO C90

[law]

 In message <20020605210128.GD5421@daikokuya.demon.co.uk>, Neil Booth writes:
 > Is HP ever going to ship a more modern compiler by default?
I have no clue.


 > Or are they effectively going to hold up this "progress" in GCC hostage
 > forever?
I don't think that converting GCC to ANSI/ISO brings us that much of a
significant improvement in GCC itself.  So I wouldn't classify this as
holding GCC progress hostage.

jeff

Re: Convert 3.2 sources to ISO C90

[Neil Booth]

law@redhat.com wrote:-

> I *still* think this is a bad idea.  In fact we've received bug reports within
> the last couple weeks due to folks trying to build on HPs using the bundled
> compiler and running into cases where ANSI-isms have crept into the sources.
> 
> We still need to support systems which don't come with an ANSI compiler.

Is HP ever going to ship a more modern compiler by default?

Or are they effectively going to hold up this "progress" in GCC hostage
forever?

Neil.

Re: Convert 3.2 sources to ISO C90

[George.R.Goffe]

Stan,

I for one agree with you, for what my opinion is worth.

Regards,

George...






Stan Shebs <shebs@apple.com>@gcc.gnu.org on 06/05/2002 01:04:20 PM

Sent by:  gcc-owner@gcc.gnu.org


To:   gcc@gcc.gnu.org
cc:

Subject:  Convert 3.2 sources to ISO C90


Now that 3.1 is out, and we've flushed lots of old obsolete configs
from the sources, it's a good time to consider dropping the
anachronistic requirement that GCC sources be written in K&R C.

Once upon a time, this was the right thing to do; there were many
systems for which only an ancient C compiler was available, and
in the absence of effective cross-compilation machinery, it was
necessary that GCC be compilable by the ancient host compiler.

The situation today is quite different.  While there may still be
hosts for which only a pre-ISO compiler is available from the
vendor (HPs come to mind), there aren't any that don't already
have a GCC port, and there is no chance that any new ones will
materialize in the future.

In fact, the era of K&R compilers is so far past that many of our
younger developers have never even seen such a compiler, and GCC's
rules of K&R compatibility are just this mumbo-jumbo that takes
cycles away from real development.  Admittedly, it's not a huge
cost, but why spend even small amounts of time on something that's
no longer needed?

So I'd like to formally propose that the K&R compatibility requirement
be dropped for 3.2, and that patches converting K&R syntax to pure
ISO be accepted as obvious improvements.

Stan

Re: Convert 3.2 sources to ISO C90

[law]

In message <3CFE7AA9.553C5298@apple.com>, Stan Shebs writes:
 > law@redhat.com wrote:
 > > 
 > > [...]  In fact we've received bug reports within
 > > the last couple weeks due to folks trying to build on HPs using the bundle
 > d
 > > compiler and running into cases where ANSI-isms have crept into the source
 > s.
 > 
 > I think it's very telling that a) the ISOisms are quietly showing
 > up over and over, and that b) there is only a small group of HP
 > users that ever notice this.
Yes, but do we want to lock them out of being able to build GCC?  That
seems so counter-intuitive as to be silly to me.

And given that the reports came in nearly immediately after GCC 3.1 was
released and multiple times I'm not sure I'd call it a "small group".

I think this would be an amazingly bad thing to do.

 > Is there some reason not to provide GCC binaries for these HP
 > users?  Are these people on new or old machines?  Has anybody
 > talked to HP about hosting the GCC binaries?  Seems like a good
 > PR move to me; I'm sure HP doesn't want to be publicly known as
 > the sole reason for GCC using pre-ISO C, doesn't sound like the
 > sort of company developers would want to support.
HP has tried to host binaries in the past.  A goodly number of the bug reports
we get are because they've always messed it up.    We really don't want to
get into the binary distribution business, particularly on a platform that
is so, err, "fun" as HPs.

jeff

Re: Convert 3.2 sources to ISO C90

[Stan Shebs]

law@redhat.com wrote:
> 
> [...]  In fact we've received bug reports within
> the last couple weeks due to folks trying to build on HPs using the bundled
> compiler and running into cases where ANSI-isms have crept into the sources.

I think it's very telling that a) the ISOisms are quietly showing
up over and over, and that b) there is only a small group of HP
users that ever notice this.

Is there some reason not to provide GCC binaries for these HP
users?  Are these people on new or old machines?  Has anybody
talked to HP about hosting the GCC binaries?  Seems like a good
PR move to me; I'm sure HP doesn't want to be publicly known as
the sole reason for GCC using pre-ISO C, doesn't sound like the
sort of company developers would want to support.

Stan

Re: Convert 3.2 sources to ISO C90

[Joseph S. Myers]

On Wed, 5 Jun 2002, Stan Shebs wrote:

> be dropped for 3.2, and that patches converting K&R syntax to pure
> ISO be accepted as obvious improvements.

Can the scripts used for converting GDB be adapted so that the basic
conversion (getting rid of PARAMS, converting all function definitions to
new-style form) can be done at one go rather than piecemeal?

(Some other benefits of such a change, e.g. being able to use string 
concatenation, being able to have function parameters of type bool, are 
probably more difficult to do automatically.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Convert 3.2 sources to ISO C90

[law]

In message <3CFE6EC4.D8655A12@apple.com>, Stan Shebs writes:
 > Now that 3.1 is out, and we've flushed lots of old obsolete configs
 > from the sources, it's a good time to consider dropping the
 > anachronistic requirement that GCC sources be written in K&R C.
 > 
 > Once upon a time, this was the right thing to do; there were many
 > systems for which only an ancient C compiler was available, and
 > in the absence of effective cross-compilation machinery, it was
 > necessary that GCC be compilable by the ancient host compiler.
 > 
 > The situation today is quite different.  While there may still be
 > hosts for which only a pre-ISO compiler is available from the
 > vendor (HPs come to mind), there aren't any that don't already
 > have a GCC port, and there is no chance that any new ones will
 > materialize in the future.
 > 
 > In fact, the era of K&R compilers is so far past that many of our
 > younger developers have never even seen such a compiler, and GCC's
 > rules of K&R compatibility are just this mumbo-jumbo that takes
 > cycles away from real development.  Admittedly, it's not a huge
 > cost, but why spend even small amounts of time on something that's
 > no longer needed?
 > 
 > So I'd like to formally propose that the K&R compatibility requirement
 > be dropped for 3.2, and that patches converting K&R syntax to pure
 > ISO be accepted as obvious improvements.
I *still* think this is a bad idea.  In fact we've received bug reports within
the last couple weeks due to folks trying to build on HPs using the bundled
compiler and running into cases where ANSI-isms have crept into the sources.

We still need to support systems which don't come with an ANSI compiler.

jeff

Re: Convert 3.2 sources to ISO C90

[Daniel Berlin]

On Wednesday, June 5, 2002, at 04:04  PM, Stan Shebs wrote:

> Now that 3.1 is out, and we've flushed lots of old obsolete configs
> from the sources, it's a good time to consider dropping the
> anachronistic requirement that GCC sources be written in K&R C.
>
> Once upon a time, this was the right thing to do; there were many
> systems for which only an ancient C compiler was available, and
> in the absence of effective cross-compilation machinery, it was
> necessary that GCC be compilable by the ancient host compiler.
>
> The situation today is quite different.  While there may still be
> hosts for which only a pre-ISO compiler is available from the
> vendor (HPs come to mind), there aren't any that don't already
> have a GCC port, and there is no chance that any new ones will
> materialize in the future.
>
> In fact, the era of K&R compilers is so far past that many of our
> younger developers have never even seen such a compiler, and GCC's
> rules of K&R compatibility are just this mumbo-jumbo that takes
> cycles away from real development.  Admittedly, it's not a huge
> cost, but why spend even small amounts of time on something that's
> no longer needed?
>
> So I'd like to formally propose that the K&R compatibility requirement
> be dropped for 3.2, and that patches converting K&R syntax to pure
> ISO be accepted as obvious improvements.
>
I agree completely.

As a datapoint, GDB has required ISO C, rather than K&R C, for a while now, and 0 complaints have been heard so far.

One could always ansi2knr all the files if need be, anyway.
--Dan

> Stan
>

Re: Convert 3.2 sources to ISO C90

[Neil Booth]

Stan Shebs wrote:-

> Now that 3.1 is out, and we've flushed lots of old obsolete configs
> from the sources, it's a good time to consider dropping the
> anachronistic requirement that GCC sources be written in K&R C.
> 
> Once upon a time, this was the right thing to do; there were many
> systems for which only an ancient C compiler was available, and
> in the absence of effective cross-compilation machinery, it was
> necessary that GCC be compilable by the ancient host compiler.
> 
> The situation today is quite different.  While there may still be
> hosts for which only a pre-ISO compiler is available from the
> vendor (HPs come to mind), there aren't any that don't already
> have a GCC port, and there is no chance that any new ones will
> materialize in the future.
> 
> In fact, the era of K&R compilers is so far past that many of our
> younger developers have never even seen such a compiler, and GCC's
> rules of K&R compatibility are just this mumbo-jumbo that takes
> cycles away from real development.  Admittedly, it's not a huge
> cost, but why spend even small amounts of time on something that's
> no longer needed?
> 
> So I'd like to formally propose that the K&R compatibility requirement
> be dropped for 3.2, and that patches converting K&R syntax to pure
> ISO be accepted as obvious improvements.

Agreed.  One of the bigger wins is string concatenation.

Neil.

Convert 3.2 sources to ISO C90

[Stan Shebs]

Now that 3.1 is out, and we've flushed lots of old obsolete configs
from the sources, it's a good time to consider dropping the
anachronistic requirement that GCC sources be written in K&R C.

Once upon a time, this was the right thing to do; there were many
systems for which only an ancient C compiler was available, and
in the absence of effective cross-compilation machinery, it was
necessary that GCC be compilable by the ancient host compiler.

The situation today is quite different.  While there may still be
hosts for which only a pre-ISO compiler is available from the
vendor (HPs come to mind), there aren't any that don't already
have a GCC port, and there is no chance that any new ones will
materialize in the future.

In fact, the era of K&R compilers is so far past that many of our
younger developers have never even seen such a compiler, and GCC's
rules of K&R compatibility are just this mumbo-jumbo that takes
cycles away from real development.  Admittedly, it's not a huge
cost, but why spend even small amounts of time on something that's
no longer needed?

So I'd like to formally propose that the K&R compatibility requirement
be dropped for 3.2, and that patches converting K&R syntax to pure
ISO be accepted as obvious improvements.

Stan