This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: cpplib and a couple others: squelch -pedantic warnings
- To: zack at wolery dot cumb dot org
- Subject: Re: cpplib and a couple others: squelch -pedantic warnings
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Thu, 4 May 2000 13:35:55 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org, jason at cygnus dot com
> From: Zack Weinberg <zack@wolery.cumb.org>
>
> > Yep, been working towards it. There are around 100 left depending on
> > platform (having start with many thousands.)
>
> Mostly from the options table in toplev.c, it appears.
Er, no. In gcc.c.
> > I usually add -Wcast-qual when using -Wwrite-strings, you may want to
> > add it too. (That only adds another 30, mostly from cpp casting away
> > const-ness in parameters passed to free().)
>
> That means it's utterly impossible to free a constant object without a
> warning, then?
AFAICT, that's correct. I'd be happy to be proven wrong. :-)
However I'm not sure why its necessary to make malloc'ed objects be
const char *. Sometimes its done when you share malloc'ed strings and
"literal" and/or const strings in the same pointer. IMHO, this is a
dangerous practice because it leads to strange errors when you
accidentally free the "literal" string. Would it be possible to stop
malloc'ing strings into const char * pointers in cpp without
de-constifying it too much?
> > We should also think about -Wstrict-prototypes, though I'm still
> > waiting for your insn-flags.h cleanup patch. What ever happened to
> > that? Still no feedback?
>
> It needs major work which I don't have time for right now. We
> need to be able to write
>
> (define_expand "call"
> [(call (match_operand:QI 0 "memory_operand" "")
> (match_operand:SI 1 "general_operand" ""))
> (ignore_operand 2)
> (ignore_operand 3)]
> ""
> "...")
>
> (define_insn ""
> [(call (match_operand:QI 0 "memory_operand" "o")
> (match_operand:SI 1 "general_operand" "g"))]
> ""
> "call %0")
>
> - the key being (ignore_operand N) which has to be supported by the
> relevant generator programs.
> zw
I think some of the parsing code for the gen* programs was consolidated
into gensupport.c, so it might be easier to do this now. At least its
all in one place...
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions