https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #17 from Kaz Kylheku <kkylheku at gmail dot com> ---
(In reply to Harald van Dijk from comment #14)
> (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.
The standrad does not define the conversion at the *type* level.
>
> > 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 program is strictly conforming because it has no problem with type. The
language defines a division operator for the types int x int -> int. There can
be divisions written x / y where we don't know that y is zero until a run-time
input is supplied.
The expression 1/0 has a meaning and is translatable; just the operand values
are bad.
Compilers have to be careful when doing constant folding not to blow up on bad
expressions that are not actually called.
Something like this could occur:
switch (sizeof (T)) {
case 4:
... 1 / (8 - sizeof (T));
case 8
... 1 / (16 - sizeof (T));
}
where if the size is 8, then case 4: never taken in that case, has a constant
division by zero. Evaluation of constants is required for dead-code
elimination, so dead code elimination cannot be counted on to remove bad
expressions.
But:
(void *) &function
has no meaning at all due to a type problem. Because it's a type problem, it is
a static problem which speaks to the ability to translate the expression. That
ability is not required.
The standard is mum about converting a function pointer type to void * type,
regardless of the specific run-time values involved.
We wouldn't say that
void f(void) { "abc" / "def"; }
is strictly conforming because f is not called in the program. There is a type
problem. Now in this case there is a constraint violation: it requires a
diagnostic.
(void *) &function has a problem in the same category: operator not defined for
the given types. The only difference is that there is no requirement for a
diagnostic.
The implementation is justified in aborting the translation. Possibly with a
diagnostic (which could say "conversion of function pointers to data pointers
is not supported, goodbye!").
In summary, (void *) &function is a type mismatch error, which is not caught
by the C type system due to there being no constraint violation. It's a hole in
the type system.
When an implementation hits a situation that triggers a hole in the type
system, it is allowed to diagnose it and reject the program.
Anyway, this is all moot because this bugzilla is about GNU C, which has the
extension. The behavior is locally defined.
We would like NOT to have a diagnostic under -Wpedantic, so we are on the same
page.
Whether your program is strictly conforming or not, we would like not to have
it diagnosed under the -Wpedantic umbrella, and even if it is changed to a
program which calls f.
There is nothing wrong with the diagnostic, but it should be uncoupled from
-Wpedantic and available under its own option. Possibly, an umbrella option
could exist for this kind of "super pedantic" errors, like
-Wconforming-extensions (warn about the use of GNU extensions that are
conforming, and thus require no diagnostic by ISO C).
