[PATCH INSTALLED]: Fix -Wc++-compat warnings in toplevel [t-z]*.c files

Gabriel Dos Reis gdr@integrable-solutions.net
Tue Jun 24 12:14:00 GMT 2008


On Tue, Jun 24, 2008 at 5:33 AM, Andrew Haley <aph@redhat.com> wrote:
> Gabriel Dos Reis wrote:
>>> Even with -Wall we get no warnings.
>>
>> That is correct; however, what that suggests is care needs
>> to be exercised when writing allocation, and that has always
>> been so (whether we make the code compilable with a C++
>> compiler or not).  In fact, the use of libiberty allocator-like
>> macros makes this issue go away.
>
> Indeed, yes.
>
>>> Is this error unlikely?  I don't think so.
>>
>> Have you found any instance in GCC codebase, or any of
>> Kaveh's patch?
>
> It's only been a couple of days!  Every time you cast a pointer you're
> punching a hole in the type system.  Every such cast removes some of
> the useful type checking done by the compiler.  Both of us know this:
> to declare that we don't need this would be to suggest that gcc
> maintainers are as gods, untainted by the errors of mere mortals.
> But I'm sure you're not suggesting such a thing.

I did no mean to imply that we do not need compiler checks.
As you probably saw in a recent comment of mine to Kaveh's
proposed catch, I suggested use of libiberty allocator-like macros.
I suspect both of us agree on that.

>
> There is no doubt, at least in my mind, that the quality and
> reliability of the code, considered as pure C, will be degraded by
> adding pointer casts in many placed.  If we can adopt practices such
> as libiberty allocator-like macros wherever possible, and make sure
> that the cast is not removed from the preprocessed source when using
> the C front end, that will surely help.

I agree.



More information about the Gcc-patches mailing list