Gabriel Dos Reis wrote:
> Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | The result of calling function pointer casted to sufficiently different
> | type is
> | a real example an undefined behavior.
>
> As I said earlier, it is fruitless to try to impose an ordering on
> the space of undefined behaviour.
>
> -- Gaby
>
My whole concern is about the rule for artificially generated trap
(turned out
to be for an ICE hiding purpose) that has been changed once more in 4.2
and yet the changed rule does not catch all cases.
As a result of such old decision, we currently have:
- different behavior for different front-ends
- may be a real cause is not fixed yet
- different developer's "workaround" for <3.3.2, 3.3.2-4.1 and 4.2 compilers
- yet there is still a syntax to generate old "undefined-behaviour"
function call,
so its a straight way for future messy changes (not to mentioned a mess
with different frontends behaviour)
I can imagine the benefit from -ftrap-on-undefined-behaviour option
(seriously speaking -Wundefined-behavior is better).
But trapping some syntaxes of the same semantic is just a straight way
to confuse developers and is not a well-established practice.
It's like trapping "i = i++" expr at the same time leaving traditional
undefined behaviour for "i = (i++)".
See, currently compiler is able to generate code for assignment cast:
double foo(double);
int (*bar)(int) = foo;
bar (0);
Why should it ICE/trap on expression cast?
((int (*)(int)) foo) (0)
Nevertheless looks like we already agreed to remove trap generation code
because:
- it does not not ICE anymore (c, c++ frontend)
- it restores "natural" platform-dependent undefined behaviour
- it makes legacy code accidentally work (like openssl casts)
Just a reminder: objective-c[++] frontend still have an ICE
for some casted function pointers and needs to be fixed
like c/c++ was already fixed.
