https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #14 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or when such conversions are possible in a cast at all (which is
> enough for rejecting the translation unit).
I disagree. You're reading something into the standard that it does not say
anywhere. It would make sense if it did say that, but it doesn't.
> And since no requirements are
> imposed relating to such conversions at either translation time or runtime,
> the definition of undefined behavior is met.
The behaviour at runtime is implicitly unspecified. The behaviour at
translation time is not, as my program does not attempt to convert between any
function and object pointer. Performing that conversion is undefined by
omission. Writing code that *would* perform that conversion, if executed, is
not undefined, because the standard defines the behaviour of code that is not
executed: it does nothing.
I am assuming, at least, that there is no dispute that
#include <stdio.h>
int main(void) {
if (0) puts("Hello, world!");
return 0;
}
has never been permitted to print "Hello, world!".
(In reply to Kaz Kylheku from comment #12)
> It does not. You're relying on the implementation (1) glossing over the
> undefined conversion at translation time (or supporting it as an extension)
I'm not.
> Undefined behavior means that the implementation is permitted to stop, at
> translation or execution time, with or without the issuance of a diagnostic
> message.
My program has no undefined behaviour. It is in the same category as
void f(void) { 1/0; }
int main(void) { return 0; }
which is strictly confirming despite the division by zero in an uncalled
function, despite division taking constant operands. The implementation is not
at liberty to treat this as translation-time undefined behaviour, because the
program does not divide by zero. Even though constant expressions could
otherwise be optimised. And GCC rightly accepts this with -pedantic-errors.
It is in the same category as
void f(x) void *x; { f(f); }
int main(void) { return 0; }
which is strictly conforming despite the unevaluated function call to an
unprototyped function with a wrong argument type where the compiler knows the
type of the parameter. And GCC rightly accepts this too with -pedantic-errors.
It does not even warn by default.
There have been DRs that explicitly address this for various forms of undefined
behaviour (#109, #132, #317). Is it really necessary for WG14 to receive a
separate DR for every category of undefined behaviour to clarify that the same
rules for undefined behaviour apply everywhere?
