This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cpplib and a couple others: squelch -pedantic warnings


 > 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]