From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B62923858D28; Tue, 2 Apr 2024 18:18:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B62923858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712081895; bh=bIo5XohJamPprofRa+i2F+np8ajsG855xUMPFodEj7o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=x4LM5KpWV41EG/llR3i6RaKzeoDdaGeTC3tNACj3p6Fh53/KdprTeSzTTErrexupg OZpWZKZPW66/OUhNZ7uU0Zo4WJjPGWu9FHWZImLQaRabodLU4lfqire27r7MzFLH5V gp+SuOW8UD2JDeFF5Afs0CuHoruyv9MzBcdUQb/U= From: "jsm28 at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114526] ISO C does not prohibit extensions: fix misconception. Date: Tue, 02 Apr 2024 18:18:15 +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: jsm28 at gcc dot gnu.org 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 #15 from Joseph S. Myers --- There are several statements such as "Any pointer type may be converted to = an integer type." and "A pointer to an object type may be converted to a point= er to a different object type.", that allow certain conversions to occur in a translation unit and are associated with some properties of those conversio= ns if they are executed. There are also statements disallowing certain convers= ions from occurring in a translation unit (for example, conversions between poin= ter and floating types are constraint violations). In the cases where there is = no statement either way, the behavior is undefined as a property of the translation unit (not just of the execution): it is not defined whether suc= h a conversion may occur in a translation unit, and not defined what the semant= ics would be on execution if an implementation permits the translation of such a conversion. Being undefined through omission of definition has, as per clau= se 4, not difference in meaning or emphasis from being explicitly undefined. I'd suggest working with the Undefined Behavior Study Group on making it mo= re explicit for each instance of undefined behavior whether it is a property of the program or of an execution thereof, but if any case seems particularly unclear, filing an issue once the new C standard issue tracker is up and running would probably be reasonable (but it seems likely that such issues would be referred to the UB study group to recommend a resolution just as floating-point issues would likely be referred to the CFP group). It's *not* the case that the same rules apply everywhere, because there are= two different kinds of UB depending on whether what's undefined is a property of the program or an execution thereof. Division by zero is obviously UB as a property of an execution, because whether a value is zero is a property of = the execution. Different types for the same identifier with external linkage in different translation units is obviously UB as a property of the program (a= nd not widely diagnosed without LTO), as the whole concept of an identifier corresponding to an object with a particular value depends on a globally consistent notion of its type and the UB is about presence of declarations rather than a particular path of execution. In some cases, as here, it may = be less obvious how to read the wording as referring to properties of an execu= tion or of a program.=