From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AA1C83858D39; Tue, 2 Apr 2024 17:57:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA1C83858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712080648; bh=uqedfhrOEmelguBnW3Aq8r6wawylbvBWSnuCvMBxL7Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C1ZHUdYC8b6m6OJgtjV6YP5F0qu4wv31SX9oi8CbMct2g8Ej68yLpr2/JeWL42VSB ScUzwena/Qre37s7XiDuQujdMZyt74TCSGOpi+vY8l/SEj0mbI2aArfYpC1c/yGgcT TSpjIQUuYpbudcLtX2Ev6DggmHjs88EIXQBVC1RA= From: "harald at gigawatt dot nl" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114526] ISO C does not prohibit extensions: fix misconception. Date: Tue, 02 Apr 2024 17:57:28 +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: harald at gigawatt dot nl 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 #14 from Harald van Dijk --- (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 runtim= e, > 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 n= ot executed: it does nothing. I am assuming, at least, that there is no dispute that #include 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 extensio= n) 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 diagnost= ic > 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 t= he 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 t= he type of the parameter. And GCC rightly accepts this too with -pedantic-erro= rs. It does not even warn by default. There have been DRs that explicitly address this for various forms of undef= ined 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 s= ame rules for undefined behaviour apply everywhere?=