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: gdr at codesourcery dot com, 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 14:58:05 -0400 (EDT)
- Cc: gcc-patches at gcc dot gnu dot org, jason at cygnus dot com
> From: Gabriel Dos Reis <gdr@codesourcery.com>
>
> Zack Weinberg <zack@wolery.cumb.org> writes:
>
> [...]
>
> | > 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?
> |
> | Actually, malloced strings are the least of the problem.
> |
> | Most of cpplib's data structures are write-once. I express that by
> | building them in non-constant variables, then setting constant
> | pointers to them. The compiler can then enforce immutability
> | everywhere else. I've found several subtle and dangerous bugs with
> | this tactic. But I still need the ability to free those data
> | structures when I'm done with them.
>
> That is the sort of thing what I'm doing with the diagnostic stuff.
> I don't find de-constifying the right thing to do, at least not as
> proposed.
> -- Gaby
How about providing a cfree() function which does the following:
> /* Provide a version of `free' which deallocates const pointers. This
> allows one to create immutable objects and free them without
> getting warnings from passing a const pointer to free or requiring
> one to cast away const-ness which makes gcc -Wcast-qual complain.
> You'll still get one cast qual warning right here of course. */
>
> void cfree(p)
> const PTR p;
> {
> free ((PTR) p);
> }
This would at least consolidate the problem into one warning. If you
guys agree with this approach, I'll stick it in xmalloc.c/libiberty.h.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions