GCC Steering Committee decision on ISO C conversion

GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

The GCC Steering Committee was asked to consider dropping traditional
(K&R) C support in the GCC sources and allow converting everything to
ISO C.  http://gcc.gnu.org/ml/gcc/2002-06/msg00337.html

Various objections were raised primarily with regards to HPUX, which
by default ships with a traditional C compiler.  (Note HPUX is
currently one of the "primary" evaluation platforms.)

Out of deference to these objections, the committee agreed on a
compromise proposal which calls for converting the parts of the source
tree which are only compiled by GCC itself, thus ensuring that HPUX
users would continue to be able to bootstrap GCC for the 3.2 release
cycle.  The committee intends to revisit this issue for the 3.3
series.  Aside from the points already raised, one of the criteria
considered when this issue is brought up again may be whether
volunteers step forward to complete converting the portions we're
opening up now.

For volunteers willing to assist with the conversion, a general rule
of thumb is that we'll keep traditional C support in the parts of GCC
compiled by the stage1 bootstrap compiler.  However to avoid
confusion, below is an explicit list of the sections where we consider
traditional C required and those where we prefer ISO C.

Volunteers are encouraged to submit patches for this conversion in the
normal fashion for approval and installation.  However removal of
PARAMS from the proper areas can be checked in under the obvious rule
as long as other standard obligations are followed (e.g. proper
testing & mention of platform where it occurred, following coding
conventions, etc.)

ISO C Preferred
---------------
All non-C language frontends (cp, java, f, objc, ada)
Target libraries and modules (libgcc, crtstuff.c, fp-bit.c, libf2c,
libobjc, libjava, etc)


Traditional C Required
----------------------
libiberty
GCC backend (anything in libbackend.a)
C frontend (files named c-*)


GCC uses zlib (supports traditional C) and fastjar (written in ISO C)
and these directories are compiled by the stage1 compiler.  However
since these packages are imported and libjava is disabled on HPUX we
don't feel the need to make changes either way to these directories.

	The GCC Steering Committee

Re: GCC Steering Committee decision on ISO C conversion

[Neil Booth]

Kaveh R. Ghazi wrote:-

> Traditional C Required
> ----------------------
> libiberty
> GCC backend (anything in libbackend.a)
> C frontend (files named c-*)

It's way more than this: it's anything compiled during stage1 right?
Which is pretty much everything immediately in gcc/.

Neil.

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: Neil Booth <neil@daikokuya.demon.co.uk>
 > 
 > Kaveh R. Ghazi wrote:-
 > 
 > > Traditional C Required
 > > ----------------------
 > > libiberty
 > > GCC backend (anything in libbackend.a)
 > > C frontend (files named c-*)
 > 
 > It's way more than this: it's anything compiled during stage1 right?
 > Which is pretty much everything immediately in gcc/.
 > Neil.

libbackend.a covers pretty much everything, but I did leave out cpp*,
sorry. :-)

However you're right it's anything compiled by the stage1 compiler.
So if anything was left out of the list use your best judgement.

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[Hans-Peter Nilsson]

On Thu, 13 Jun 2002, Kaveh R. Ghazi wrote:
> The GCC Steering Committee was asked to consider dropping traditional
> (K&R) C support in the GCC sources and allow converting everything to
> ISO C.  http://gcc.gnu.org/ml/gcc/2002-06/msg00337.html

From time to time non-ISO C89 code but valid ISO C99 (and C++)
code creeps into the compiler: specifically declarations of
variables after the first statement in a block:

 {
   int i;
   doit ();
   int j;
   ...
 }

As long as cross-compilers are supposed to be buildable with
gcc-2.95, I suggest that "ISO C" should be further qualified as
"ISO C89" (or whatever the correct standardese term is).
Necessary only for the "non-C language frontends" file group, of
course.

brgds, H-P

Re: GCC Steering Committee decision on ISO C conversion

[Gabriel Dos Reis]

Hans-Peter Nilsson <hp@bitrange.com> writes:

[...]

| "ISO C89" (or whatever the correct standardese term is).

There is no ISO C89; there an ISO C90 :-)

I know GCC/gcc insists on saying ISO C89, but that is incorrect and
I'll submit a patch to correct that anachronism.

-- Gaby

Re: GCC Steering Committee decision on ISO C conversion

[Joseph S. Myers]

On 13 Jun 2002, Gabriel Dos Reis wrote:

> I know GCC/gcc insists on saying ISO C89, but that is incorrect and
> I'll submit a patch to correct that anachronism.

So, you disagree with Phil's reasoning in
http://gcc.gnu.org/ml/gcc/2000-08/msg00132.html
(the only response I got about choice of name in diagnostics that gave a
preference between the two)?

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

Re: GCC Steering Committee decision on ISO C conversion

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On 13 Jun 2002, Gabriel Dos Reis wrote:
| 
| > I know GCC/gcc insists on saying ISO C89, but that is incorrect and
| > I'll submit a patch to correct that anachronism.
| 
| So, you disagree with Phil's reasoning in
| http://gcc.gnu.org/ml/gcc/2000-08/msg00132.html

Yes, I disagree with that reasoning: There were an ANSI C89 but no ISO C89.

| (the only response I got about choice of name in diagnostics that gave a
| preference between the two)?

Sorry, I missed that thread.

There seems to be some confusion.  I'm not sure it is a good thing to
keep it on.

There is an interesting summary in

  http://sources.redhat.com/ml/gdb/2002-06/msg00026.html

and associated followups.

-- Gaby
 

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: Hans-Peter Nilsson <hp@bitrange.com>
 > 
 > I suggest that "ISO C" should be further qualified as "ISO C89" (or
 > whatever the correct standardese term is).  Necessary only for the
 > "non-C language frontends" file group, of course.
 > brgds, H-P

Definitely not C99.  I thought it was obvious, but I should have been
explicit that we're talking about allowing ISO C90 (or C89 if you
prefer to call it that.)

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[Phil Edwards]

Let me just ask for clarifcation on a point here:

> ISO C Preferred
> ---------------
> All non-C language frontends (cp, java, f, objc, ada)
> 
> Traditional C Required
> ----------------------
> C frontend (files named c-*)

So, we can convert the C++ front-end to happy C, but if that code is
later merged into the C front end -- as is the goal, I'm told -- we have
to convert it back to crappy C?


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC Steering Committee decision on ISO C conversion

[Florian Weimer]

Phil Edwards <phil@jaj.com> writes:

> So, we can convert the C++ front-end to happy C, but if that code is
> later merged into the C front end -- as is the goal, I'm told -- we have
> to convert it back to crappy C?

At this point, K&R support can be dropped.

Personally, I don't see much value in supporting K&R compiler for the
sake of obsolescent proprietary operating systems anyway. ;-)

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: Phil Edwards <phil at jaj dot com> 
 > 
 > Let me just ask for clarifcation on a point here:
 > 
 > > ISO C Preferred
 > > ---------------
 > > All non-C language frontends (cp, java, f, objc, ada)
 > > 
 > > Traditional C Required
 > > ----------------------
 > > C frontend (files named c-*)
 > 
 > So, we can convert the C++ front-end to happy C, but if that code is
 > later merged into the C front end -- as is the goal, I'm told -- we
 > have to convert it back to crappy C?
 > Phil

Yes.  Though if you wait long enough, a future release of GCC may be
entirely C90.  For now we're just talking about the 3.2 series.

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[Daniel Berlin]

>  > So, we can convert the C++ front-end to happy C, but if that code is
>  > later merged into the C front end -- as is the goal, I'm told -- we
>  > have to convert it back to crappy C?
>  > Phil
> 
> Yes.  Though if you wait long enough, a future release of GCC may be
> entirely C90.  For now we're just talking about the 3.2 series.

And if we wait long enough, all the HPUX boxes without a compiler that 
supports ISO C will die and not be able to get replacement parts.
I think it's pretty much a toss up which will occur first.

--Dan

Re: GCC Steering Committee decision on ISO C conversion

[Joseph S. Myers]

On Thu, 13 Jun 2002, Kaveh R. Ghazi wrote:

> For volunteers willing to assist with the conversion, a general rule
> of thumb is that we'll keep traditional C support in the parts of GCC
> compiled by the stage1 bootstrap compiler.  However to avoid
> confusion, below is an explicit list of the sections where we consider
> traditional C required and those where we prefer ISO C.

> Traditional C Required
> ----------------------
> libiberty
> GCC backend (anything in libbackend.a)

Does this require traditional C for target files in gcc/config/ for
targets that are only used for cross-compilation, or which don't have any
non-ISO bootstrap compiler?

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

Re: GCC Steering Committee decision on ISO C conversion

[Aldy Hernandez]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

 > Does this require traditional C for target files in gcc/config/ for
 > targets that are only used for cross-compilation, or which don't have any
 > non-ISO bootstrap compiler?

Heh!  Good point.

Perhaps all targets except config/hp/* should be allowed to use ISO C. :)

Aldy

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: Aldy Hernandez <aldyh@redhat.com>
 > 
 > >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
 > 
 >  > Does this require traditional C for target files in gcc/config/
 >  > for targets that are only used for cross-compilation, or which
 >  > don't have any non-ISO bootstrap compiler?

We're not converting config/* yet.


 > Heh!  Good point.
 > Perhaps all targets except config/hp/* should be allowed to use ISO C. :)
 > Aldy

Perhaps a good idea for the next release series.

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[Eric Christopher]

>  > Heh!  Good point.
>  > Perhaps all targets except config/hp/* should be allowed to use ISO
>  > C. :) Aldy
> 
> Perhaps a good idea for the next release series.

I'm sure you've checked IRIX then? I've had occasional problems with
non-K&R code on the platform...

-eric

 

-- 
I will not carve gods

Re: GCC Steering Committee decision on ISO C conversion

[David O'Brien]

On Fri, Jun 14, 2002 at 10:14:22AM -0400, Kaveh R. Ghazi wrote:
>  > From: Aldy Hernandez <aldyh@redhat.com>
>  > 
>  > >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
>  > 
>  >  > Does this require traditional C for target files in gcc/config/
>  >  > for targets that are only used for cross-compilation, or which
>  >  > don't have any non-ISO bootstrap compiler?
> 
> We're not converting config/* yet.

Why?  I would really like to use string concatenation in freebsd.h files.
Why hold my OS back for HP braindeadness?
 
-- 
-- David    (obrien@NUXI.com)

Re: GCC Steering Committee decision on ISO C conversion

[Stan Shebs]

David O'Brien wrote:
> 
> On Fri, Jun 14, 2002 at 10:14:22AM -0400, Kaveh R. Ghazi wrote:
> >  > From: Aldy Hernandez <aldyh@redhat.com>
> >  >
> >  > >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
> >  >
> >  >  > Does this require traditional C for target files in gcc/config/
> >  >  > for targets that are only used for cross-compilation, or which
> >  >  > don't have any non-ISO bootstrap compiler?
> >
> > We're not converting config/* yet.
> 
> Why?  I would really like to use string concatenation in freebsd.h files.
> Why hold my OS back for HP braindeadness?

For the same reason that ginclude/stddef.h is a nightmare of ifdefs,
many of them required by BSD braindeadness. :-)  We all make
compromises for the sake of being able to work together.

None of these choices are set in stone either.  The SC has already
proposed to revisit the issue for 3.3, which isn't that many
months away...

Stan

Re: GCC Steering Committee decision on ISO C conversion

[David O'Brien]

On Thu, Jun 27, 2002 at 06:59:59PM -0700, Stan Shebs wrote:
> > > We're not converting config/* yet.
> > 
> > Why?  I would really like to use string concatenation in freebsd.h files.
> > Why hold my OS back for HP braindeadness?
> 
> For the same reason that ginclude/stddef.h is a nightmare of ifdefs,
> many of them required by BSD braindeadness. :-)  We all make
> compromises for the sake of being able to work together.

ginclude/stddef.h is used everywhere.  config/freebsd*.h *might* be used
by 0.0001% of the HP-UX users.
 
> None of these choices are set in stone either.  The SC has already
> proposed to revisit the issue for 3.3, which isn't that many
> months away...

It is _years_ away from my perspective.  GCC 3.1 just went into FreeBSD.
Depending on when 3.2 is released, how much bugs it fixes on AMD x86-64
and IA-64; it could be until FreeBSD 6.0 (probably 2 years away) until we
can upgrade to it.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: "David O'Brien" <obrien@NUXI.com>
 > 
 > On Fri, Jun 14, 2002 at 10:14:22AM -0400, Kaveh R. Ghazi wrote:
 > >  > From: Aldy Hernandez <aldyh@redhat.com>
 > >  > 
 > >  > >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
 > >  > 
 > >  >  > Does this require traditional C for target files in gcc/config/
 > >  >  > for targets that are only used for cross-compilation, or which
 > >  >  > don't have any non-ISO bootstrap compiler?
 > > 
 > > We're not converting config/* yet.
 > 
 > Why?  I would really like to use string concatenation in freebsd.h files.
 > Why hold my OS back for HP braindeadness?

David,

My sentence above was a statement of official policy.  I.e. we're not
going to convert any config directory wholesale.  That's the
parameters of the proposal the SC voted through.  I don't have the
authority to change it unilaterally myself.

Operationally, if you do use string concatenation in the freebsd
files, you'll probably get -Wtraditional warnings about it.  I'm not
interested in turning -Wtraditional off (even just for freebsd)
because then other ISO C stuff will creep in to the general parts of
the compiler through bit-rot.

OTOH, my personal opinion is let's be practical.  If you submit a
patch to a freebsd specific file with a string concatenation in it, no
one will probably care (as long as you're happy living with the extra
warning.)  E.g. the solaris2 port uses string concatenation in the
specs stuff and no one minds.  I just live with the extra warning when
I bootstrap there.

And I'll let you in on a little secret.  I believe the HP's
traditional compiler *understands* string concatenation!

Why do I say this?  Because libiberty/regex.c uses it an no one has
complained.  Maybe someone can confirm this...

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[Richard Earnshaw]

ghazi@caip.rutgers.edu said:
> And I'll let you in on a little secret.  I believe the HP's
> traditional compiler *understands* string concatenation!

> Why do I say this?  Because libiberty/regex.c uses it an no one has
> complained.  Maybe someone can confirm this... 

Actually, regex.c has:

#  if defined (__STDC__) || defined (ALMOST_STDC) || defined 
(HAVE_STRINGIZE)
#   define PREFIX(name) wcs_##name
#   define ARG_PREFIX(name) c##name
#  else
#   define PREFIX(name) wcs_/**/name
#   define ARG_PREFIX(name) c/**/name
#  endif

So traditional compilers can use the traditional pasting method.

That doesn't necessarily mean that the old HPUX C compiler doesn't support 
string pasting, just that you can't use this code as an assertion that it 
does.

R.

Re: GCC Steering Committee decision on ISO C conversion

[Andreas Schwab]

Richard Earnshaw <rearnsha@arm.com> writes:

|> ghazi@caip.rutgers.edu said:
|> > And I'll let you in on a little secret.  I believe the HP's
|> > traditional compiler *understands* string concatenation!
|> 
|> > Why do I say this?  Because libiberty/regex.c uses it an no one has
|> > complained.  Maybe someone can confirm this... 
|> 
|> Actually, regex.c has:
|> 
|> #  if defined (__STDC__) || defined (ALMOST_STDC) || defined 
|> (HAVE_STRINGIZE)
|> #   define PREFIX(name) wcs_##name
|> #   define ARG_PREFIX(name) c##name
|> #  else
|> #   define PREFIX(name) wcs_/**/name
|> #   define ARG_PREFIX(name) c/**/name
|> #  endif

That's token pasting, not string concatenation.  You cannot emulate the
latter in pre-standard compilers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC Steering Committee decision on ISO C conversion

[Richard Earnshaw]

> That's token pasting, not string concatenation.  You cannot emulate the
> latter in pre-standard compilers.

Doh! Of course.

R.

Re: GCC Steering Committee decision on ISO C conversion

[Richard Sandiford]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> The GCC Steering Committee was asked to consider dropping traditional
> (K&R) C support in the GCC sources and allow converting everything to
> ISO C.  http://gcc.gnu.org/ml/gcc/2002-06/msg00337.html

Sorry if I've missed it, but is there a list of what changes you mean?
Or is that still to be decided?

Like, is it just removing PARAMS for now?  Or are we going to start
using new-style function declarations?  Convert boolean parameters
to 'bool' instead of 'int'?

Richard

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: Richard Sandiford <rsandifo@redhat.com> 
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > 
 > > The GCC Steering Committee was asked to consider dropping traditional
 > > (K&R) C support in the GCC sources and allow converting everything to
 > > ISO C.  http://gcc.gnu.org/ml/gcc/2002-06/msg00337.html
 > 
 > Sorry if I've missed it, but is there a list of what changes you mean?
 > Or is that still to be decided?
 > 
 > Like, is it just removing PARAMS for now?  Or are we going to start
 > using new-style function declarations?  Convert boolean parameters
 > to 'bool' instead of 'int'?
 > Richard

I highlighted PARAMS removal because its something we'll allow as
"obvious" checkins.  But there's a lot more we can do for ISO C90
conversion.

E.g. as you suggested above, you can convert to the new function
definitions and use bool parameters.  But you can also convert
VPARAMS, DEFUN, PTR, VA_OPEN (really VA_*).  Also stuff from symcat.h,
namely CONCAT* and STRINGX.  You can also rely on using string
concatenation and other ISO C90 features if the current code was
uglified for traditional C compatibility.

All of these need to go through the standard review and approval
process and adhere to our coding style conventions but are definitely
part of the conversion.

I probably left something out, but use ISO C90 as your guide.

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[Dave Hudson]

Hi,

Kaveh R. Ghazi wrote:
> I probably left something out, but use ISO C90 as your guide.

Does anyone know where ISO C90 (ISO/IEC9899:1990) can be obtained from? 
  Both the ISO and ANSI electronic stores now only carry C99 
(ISO/IEC9899:1999) and its technical corrigendum.


Thanks,
Dave

Re: GCC Steering Committee decision on ISO C conversion

[Alan Lehotsky]

At 3:58 PM +0100 6/14/02, Dave Hudson wrote:
>Hi,
>
>Kaveh R. Ghazi wrote:
>>I probably left something out, but use ISO C90 as your guide.
>
>Does anyone know where ISO C90 (ISO/IEC9899:1990) can be obtained 
>from?  Both the ISO and ANSI electronic stores now only carry C99 
>(ISO/IEC9899:1999) and its technical corrigendum.

	Think it's ONLY available in hard copy.  IIRC, there's a 
company called something like
	Global Engineering that carries these things.  My copy cost 
$50-$75 back in 1990.

	The new electronic versions are real bargains in comparison

>
>Thanks,
>Dave


-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: GCC Steering Committee decision on ISO C conversion

[Robert Lipe]

Dave Hudson wrote:

> Does anyone know where ISO C90 (ISO/IEC9899:1990) can be obtained from? 

There is a book that's now out of print called "The Annotated ANSI C
Standard" that contains the text of the spec.  As long as you stay on
the pages that quote the spec and not the authors "value add" comments,
you'll be OK.  This was a moderately popular college text, so it can
sometimes be found at various online or campus used book stores.

RJL

Re: GCC Steering Committee decision on ISO C conversion

[Richard Earnshaw]

> ... But there's a lot more we can do for ISO C90
> conversion.

> E.g. as you suggested above, you can convert to the new function
> definitions and use bool parameters.  

IIRC bool wasn't added until C95; I certainly can't find any mention of it 
in c90.

R.

Re: GCC Steering Committee decision on ISO C conversion

[Jakub Jelinek]

On Fri, Jun 14, 2002 at 03:59:14PM +0100, Richard Earnshaw wrote:
> > ... But there's a lot more we can do for ISO C90
> > conversion.
> 
> > E.g. as you suggested above, you can convert to the new function
> > definitions and use bool parameters.  
> 
> IIRC bool wasn't added until C95; I certainly can't find any mention of it 
> in c90.

That's not relevant here, since if stdbool.h is not provided and ISO C99
compiler is not used, bool will be define:
typedef char _Bool;
# define bool _Bool
so it is all about whether we can use char parameters.

	Jakub

Re: GCC Steering Committee decision on ISO C conversion

[Richard Sandiford]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> E.g. as you suggested above, you can convert to the new function
> definitions and use bool parameters.  But you can also convert
> VPARAMS, DEFUN, PTR, VA_OPEN (really VA_*).  Also stuff from symcat.h,
> namely CONCAT* and STRINGX.  You can also rely on using string
> concatenation and other ISO C90 features if the current code was
> uglified for traditional C compatibility.

OK.  I was thinking really about whether there were going to be
new coding conventions.  Like, is the new-style function definition
syntax going to be the "official" way of writing functions, in the
parts are now ISO C only?  Or will we stick to the old style?
That's only one example, of course.

Richard

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: Richard Sandiford <rsandifo@redhat.com>
 > 
 > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
 > > E.g. as you suggested above, you can convert to the new function
 > > definitions and use bool parameters.  But you can also convert
 > > VPARAMS, DEFUN, PTR, VA_OPEN (really VA_*).  Also stuff from symcat.h,
 > > namely CONCAT* and STRINGX.  You can also rely on using string
 > > concatenation and other ISO C90 features if the current code was
 > > uglified for traditional C compatibility.
 > 
 > OK.  I was thinking really about whether there were going to be
 > new coding conventions.  Like, is the new-style function definition
 > syntax going to be the "official" way of writing functions, in the
 > parts are now ISO C only?  Or will we stick to the old style?
 > That's only one example, of course.
 > Richard

Yes, in the ISO C90 sections we want to use the ISO C90 function
definition style.  (Certainly for new functions that one writes.)

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[David O'Brien]

On Thu, Jun 13, 2002 at 11:29:56AM -0400, Kaveh R. Ghazi wrote:
> Various objections were raised primarily with regards to HPUX, which
> by default ships with a traditional C compiler.  (Note HPUX is
> currently one of the "primary" evaluation platforms.)

I really don't care if a FreeBSD cross compiler can be built on HPUX
using the stock compiler.  Can non-HP targets (ie, config/<cpu !=
hppa>/*) be writen in ISO-C?
 
-- 
-- David    (obrien@NUXI.com)

Re: GCC Steering Committee decision on ISO C conversion

['David Scott Urban]

Found this searching ysing Altavista:

ANSI C89 or ISO C90 is still currently available but only in paper form. For
instance, Global Engineering Documents was carrying C89 (X3.159). Once at that
link, click US, enter "x3.159" in the document number (NOT the document title)
search box, and that'll get you the latest info from Global on this paper 
document (last we checked it was US$148) 

This was from a page dated Dec, 2001.

Hope this helps,


D. S. Urban   
email : urban@ast.lmco.com
-------------------------------------------------------------------------------
To be the person, you must know the person. To know the person, you must
understand the person. To understand the person, you must listen. To listen,
you must open your mind and put aside all preconceived ideas and notions.
-------------------------------------------------------------------------------
All opinions expressed are my own not that of my employer



>> From gcc-return-55097-urban=ast.lmco.com@gcc.gnu.org Fri Jun 14 08:58 MDT 
2002
>> Date: Fri, 14 Jun 2002 15:58:08 +0100
>> From: Dave Hudson <dave@cyclicode.net>
>> Subject: Re: GCC Steering Committee decision on ISO C conversion
>> To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
>> Cc: gcc@gcc.gnu.org
>> MIME-version: 1.0
>> Content-transfer-encoding: 7BIT
>> Delivered-to: mailing list gcc@gcc.gnu.org
>> Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
>> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
>> X-Accept-Language: en-gb, en-us
>> List-Post: <mailto:gcc@gcc.gnu.org>
>> List-Unsubscribe: <mailto:gcc-unsubscribe-urban=ast.lmco.com@gcc.gnu.org>
>> List-Archive: <http://gcc.gnu.org/ml/gcc/>
>> List-Help: <http://gcc.gnu.org/ml/>
>> 
>> Hi,
>> 
>> Kaveh R. Ghazi wrote:
>> > I probably left something out, but use ISO C90 as your guide.
>> 
>> Does anyone know where ISO C90 (ISO/IEC9899:1990) can be obtained from? 
>>   Both the ISO and ANSI electronic stores now only carry C99 
>> (ISO/IEC9899:1999) and its technical corrigendum.
>> 
>> 
>> Thanks,
>> Dave
>> 

Re: GCC Steering Committee decision on ISO C conversion

[Bonzini]

> From time to time non-ISO C89 code but valid ISO C99 (and C++)
> code creeps into the compiler: specifically declarations of
> variables after the first statement in a block:

Is it possible to add a warning for this, or to add a new language dialect
`gnu89' that allows GNU extensions that predate C99, but not C99-isms like
this that are bound to fail on C89 compilers?

|_  _  _ __
|_)(_)| ),'
------- '---

Re: GCC Steering Committee decision on ISO C conversion

[Robert Dewar]

A comparable data point with Ada. Ada 83 was actually standardized
by ISO in 87, but no one would dream of ever saying Ada 87 :-)

Re: GCC Steering Committee decision on ISO C conversion

[John David Anglin]

> And I'll let you in on a little secret.  I believe the HP's
> traditional compiler *understands* string concatenation!
> 
> Why do I say this?  Because libiberty/regex.c uses it an no one has
> complained.  Maybe someone can confirm this...

While the hpux11 native compiler can build libiberty/regex.c in 32-bit
mode (don't know about 64-bit), pcc based systems definitely choke
compiling it (eg., vax-ultrix).  Thus, let me be the first to complain ;-)
Since libiberty is used for more than gcc, I think this needs to be fixed.

A whole bunch of ISO stuff has snuck into 3.2.  Fortunately, 3.1.1
still will build all languages but java) starting with the
native C compiler.  The java build fails because it needs libiconv.
There is ISO stuff in iconv.h and the configure test fails.
Possibly if the configure test defined "const" to be "", this could
be fixed.

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

Re: GCC Steering Committee decision on ISO C conversion

[Tom Tromey]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

John> The java build fails because it needs libiconv.

Is there a PR for this?
The intent was that the iconv support be optional.
As far as I'm aware, it actually is.

Tom

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
 > 
 > While the hpux11 native compiler can build libiberty/regex.c in 32-bit
 > mode (don't know about 64-bit),

Thanks for the confirm.

 > pcc based systems definitely choke compiling it (eg., vax-ultrix).
 > Thus, let me be the first to complain ;-) Since libiberty is used
 > for more than gcc, I think this needs to be fixed.

If you're going to submit a patch, see this discussion:
http://gcc.gnu.org/ml/gcc-patches/2001-11/subjects.html#01002

Given Ulrich's reaction to incorporating K&R compat back into glibc,
we'll have to maintain our own copy.  I think we should keep any
changes to a minimum so we don't diverge from the "master" regex.c
copy too much.  Please keep that in mind when you figure out what to
do.


 > A whole bunch of ISO stuff has snuck into 3.2.

Er, "whole bunch"?  I found one nit in gengtype.c which I fixed.
What else is causing trouble?  (And for where, hpux or vax-ultrix?)

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[John David Anglin]

> Given Ulrich's reaction to incorporating K&R compat back into glibc,
> we'll have to maintain our own copy.  I think we should keep any
> changes to a minimum so we don't diverge from the "master" regex.c
> copy too much.  Please keep that in mind when you figure out what to
> do.

See PR 7170.  The main problem is the string concatenation used in the
definition of re_error_msgid.  If you have thoughts on a good way to
fix this let me know.

>  > A whole bunch of ISO stuff has snuck into 3.2.
> 
> Er, "whole bunch"?  I found one nit in gengtype.c which I fixed.
> What else is causing trouble?  (And for where, hpux or vax-ultrix?)

They affect both.  I filed a couple of PRs: 7162 and 7163 for hpux.
You may have fixed some or all of the problems in 7162.  There are
more problems of a similar nature which I didn't file as it was
getting late when I tried the build.

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

Re: GCC Steering Committee decision on ISO C conversion

[Kaveh R. Ghazi]

 > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
 > 
 > See PR 7170.  The main problem is the string concatenation used in the
 > definition of re_error_msgid.  If you have thoughts on a good way to
 > fix this let me know.

I know the problem, in fact gcc-3.x -Wtraditional warns about it when
compiling regex.c.  But I don't have any suggestions on how to fix it
that are clean and/or minimally invasive.

However AFAICT, we don't actually use libibety's regex.o anywhere in
gcc so maybe you can just not compile it if configure determines that
your stage1 compiler is lame. (?)


 > >  > A whole bunch of ISO stuff has snuck into 3.2.
 > > 
 > > Er, "whole bunch"?  I found one nit in gengtype.c which I fixed.
 > > What else is causing trouble?  (And for where, hpux or vax-ultrix?)
 > 
 > They affect both.  I filed a couple of PRs: 7162 and 7163 for hpux.
 > You may have fixed some or all of the problems in 7162.  There are
 > more problems of a similar nature which I didn't file as it was
 > getting late when I tried the build.
 > Dave

Yes, I fixed the first part of 7162 here:
http://gcc.gnu.org/ml/gcc-patches/2002-06/msg02307.html
what remains is the ISO C function definition of `open_base_files'.

Of the two traditional compilers I have (gcc -traditional and solaris2
cc -Xs) neither one complains about string concatenation or for that
matter ISO C decls/defs.  So the latter half of 7162 didn't come up in
my environment.  Honestly, I think you should have just fixed this one
rather than filing a PR...

What I think would help with function defs is if I could get
-Wtraditional to warn about any ISO C style usage.  Then everyone
would notice them even in ISO C mode.  But the C parser is
sufficiently brittle that it was hard to get it right for all cases.
Maybe I'll try again.


Regarding 7163, this doesn't occur for me either and the warning
message doesn't say where the second half of the conflict occurred.
You need to provide preprocessed source for me to be able to offer any
assistance.

		--Kaveh
--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Solutions

Re: GCC Steering Committee decision on ISO C conversion

[John David Anglin]

>  > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>  > 
>  > See PR 7170.  The main problem is the string concatenation used in the
>  > definition of re_error_msgid.  If you have thoughts on a good way to
>  > fix this let me know.
> 
> I know the problem, in fact gcc-3.x -Wtraditional warns about it when
> compiling regex.c.  But I don't have any suggestions on how to fix it
> that are clean and/or minimally invasive.
> 
> However AFAICT, we don't actually use libibety's regex.o anywhere in
> gcc so maybe you can just not compile it if configure determines that
> your stage1 compiler is lame. (?)

What about the other packages that use libiberty (eg., binutils)?  If
gcc will build the C language using the native tools, then the above
could be a viable bootstrap approach.

I guess what could be done is to initialize re_error_msgid at runtime
in a manner similar to re_syntax_table if the stage1 compiler doesn't
support string concatenation.

> Regarding 7163, this doesn't occur for me either and the warning
> message doesn't say where the second half of the conflict occurred.
> You need to provide preprocessed source for me to be able to offer any
> assistance.

I will try to go through these in detail after the holiday and provide
patches.  

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