This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Steering Committee decision on ISO C conversion
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- To: dave at hiauly1 dot hia dot nrc dot ca
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 30 Jun 2002 15:03:44 -0400 (EDT)
- Subject: Re: GCC Steering Committee decision on ISO C conversion
- References: <200206301708.g5UH80Oq019671@hiauly1.hia.nrc.ca>
> 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