Re: gcc 4.2 more strict check for "function called through a non-compatible type"

[Yuri Pudgorodsky <yur at ptci dot ru>]

>
> What happens when a target comes along and passes different pointers
> types
> differently.  Like say a floating point pointer in the FP register and an
> pointer to an integer in the general purpose register, wouldn't that also
> break the code in question?  Yes this is in theory but still saying we
> are
> breaking existing working code is bogus in this case.  The above
> reason is
> one of the reasons why this code is undefined because it does not make
> sense.

There is at least one real example of breaking existing working code -
openssl.
It compiles and passes tests using gcc 3.3-4.1.
It compiles and tests barfs a trap using gcc-4.2.
>
> Is it really working after all is the real question and I say no it
> can never
> work correctly on any target.  
Didn't you want to say "it can never work correctly on *all* targets"?

> I showed a better example where passing a fp
> value and the function expects it in the general purpose register.  Which
> happens on most targets except for x86 (32bit only in fact).
>
> -- Pinski
I don't want to say that type-casting function pointers is a good idea.
But some developers may have their own motivations and opinion.
After all, C is one of hybrid type language - with high level abstractions
and still allows low-level techniques.

Teaching developers  with a trap is a bad idea - as I already shown on
that openssl example they just find another workaround.

And not compiling previously working code mostly hurts joe users instead.