From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5803E3858D28; Tue, 2 Apr 2024 19:41:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5803E3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712086913; bh=RAaOgMfKj09snRz9WS3U6qXhvMeDGxEI4Gpadg9xpdI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=b1+e2IqTgvQm8H+oQhqSRdNG04l6CWZuh2Q/ukfb8RQN2+1crcBxYpJ1TiLW8zwnv PN5GCHuc1lhyJNWdTprEi53kkuMr6WDsbTyDVYgmgWoDMhVT8e47a3+uyAb9wZt8bg tDDYlAeThjMUiaz9mg5V12k5usrKD6f7b6+8WZfs= From: "kkylheku at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114526] ISO C does not prohibit extensions: fix misconception. Date: Tue, 02 Apr 2024 19:41:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: diagnostic, documentation X-Bugzilla-Severity: normal X-Bugzilla-Who: kkylheku at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114526 --- Comment #17 from Kaz Kylheku --- (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). >=20 > I disagree. You're reading something into the standard that it does not s= ay > 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. >=20 > > And since no requirements are > > imposed relating to such conversions at either translation time or runt= ime, > > the definition of undefined behavior is met. >=20 > 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. >=20 > I am assuming, at least, that there is no dispute that >=20 > #include > int main(void) { > if (0) puts("Hello, world!"); > return 0; > } >=20 > has never been permitted to print "Hello, world!". >=20 > (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 extens= ion) >=20 > I'm not. >=20 > > Undefined behavior means that the implementation is permitted to stop, = at > > translation or execution time, with or without the issuance of a diagno= stic > > message. >=20 > My program has no undefined behaviour. It is in the same category as >=20 > void f(void) { 1/0; } > int main(void) { return 0; } >=20 > 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-t= ime input is supplied. The expression 1/0 has a meaning and is translatable; just the operand valu= es 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 consta= nt 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, i= t is a static problem which speaks to the ability to translate the expression. T= hat 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 t= ype 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 pointe= rs is not supported, goodbye!"). In summary, (void *) &function is a type mismatch error, which is not ca= ught by the C type system due to there being no constraint violation. It's a hol= e 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 s= ame page. Whether your program is strictly conforming or not, we would like not to ha= ve 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 opti= on 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).=