This is the mail archive of the
mailing list for the GCC project.
Re: A const-ify patch for gperf generated files
- To: law at cygnus dot com
- Subject: Re: A const-ify patch for gperf generated files
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sun, 28 Mar 1999 22:01:38 -0500 (EST)
- Cc: egcs-patches at egcs dot cygnus dot com
> From: Jeffrey A Law <email@example.com>
> In message <199903272125.QAA13030@caip.rutgers.edu>you write:
> > This const-ify patch patch gets rid of around 900
> > -Wwrite-strings warnings in the gperf generated files used in egcs.
> > Okay to install?
> > --Kaveh
> > Sat Mar 27 12:39:51 1999 Kaveh R. Ghazi <firstname.lastname@example.org>
> > * Makefile.in (c-gperf.h): Generate using gperf language 'C', not
> > 'KR-C', so gperf uses the `const' keyword on strings.
> > * c-parse.gperf (resword): Const-ify a char*.
> Err, does using "C" vs "KR-C" have any other effects other than const?
Nope, that's all it does. Quoting from gperf.info, the three
gperf C language variants are:
Old-style K&R C. This language is understood by
old-style C compilers and ANSI C compilers, but
ANSI C compilers may flag warnings (or even errors)
because of lacking `const'.
Common C. This language is understood by ANSI C
compilers, and also by old-style C compilers,
provided that you `#define const' to empty for
compilers which don't know about this keyword.
ANSI C. This language is understood by ANSI C
compilers and C++ compilers.
Language "C" is exactly what we want, that's what our hand written
code looks like. So may I install it?
> I'd really prefer us to spend time fixing the basic -W -Wall warnings
> instead of -Wwrite-strings, -Wstrict-prototypes, etc.
The -W -Wall bits are steadily getting done. I've been focusing
on cleaning up the java directory. (I actually starting doing the
-Wstrict-prototypes ones at your request, though to be fair you said you
preferred prototypes over constipation, not over basic -W -Wall.)
I simply enjoy doing several at once. It keep me from getting bored.
If you want me to focus exclusively on -W -Wall for 1.2 I can do that.
> We also need to shift our focus away from warning fixes to egcs-1.2 issues.
This is understandable. If you'd like to freeze warning work
so you're not burdened reviewing too many patches, I'll hold off till
after 1.2. Just let me know which situation it is.
PS: I assume its okay to continue working with other maintainers who
are amenable since that won't involve your time? I've still got some
stuff I'd like to get done before the cutoff.
Kaveh R. Ghazi Engagement Manager / Project Services
email@example.com Qwest Internet Solutions