From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 86ACA3858C55; Wed, 3 Apr 2024 05:48:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 86ACA3858C55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712123323; bh=WaUJpyLjaEfsHd+Q8wodgyCPMXsBN35XcFzzyxdiRJg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GonDf+LofBPLaV5jURNa9u7+YCiATvcjDE9J1gUUOlZB1Oq0DvFLlEFPcIvtq7hWU wW2rwmxSsZwN3pD1DgdK53TWGt7Qx4xxjkVESrJ+yPAZAHzyUNTpFAs36pJKdTvjP/ GHYlHEa/oLdKjBapvv0tfESgvjpY9JEOV47Rlh6k= 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: Wed, 03 Apr 2024 05:48:42 +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 #19 from Kaz Kylheku --- (In reply to Harald van Dijk from comment #18) > (In reply to Kaz Kylheku from comment #17) > > The standrad does not define the conversion at the *type* level. > > ... > > The program is strictly conforming because it has no problem with type. >=20 > The DRs I referenced include ones where type errors have explicitly been > stated not to render behaviour undefined. >=20 > DR 132 (C90): >=20 > /* No headers included */ > int checkup() > { > /* Case 1 */ > if (0) > printf("Printing.\n"); > /* Case 2 */ > return 2 || 1 / 0; > }=20 >=20 > Response: "The Response to Defect Report #109 addresses this issue. The > translation unit must be successfully translated." Note that this report response does not say that the translation unit must also be successfully linked, in a hosted implementation, to produce a program. > This, despite the fact that it implicitly declares as int(*)(), which is > incompatible with the type it is meant to be declared as. A mismatch, in linkage, can only occur when a reference is of a different type from the definition. In this translation unit alone, there is no type mismatch, because the unit contains only a reference to printf, and no definition. The translation unit can be part of a program where it makes sense. E.g. in a freestanding implementation, where there isn't a library with a printf, another translation unit can supply a compatible definition of printf. Then, if (0) can be flipped to if (1) and checkup() can be called, even. There is no type problem here whatsoever that is comparable to an operator being given operands whose type combination is not defined for the operator. That's a problem entirely confined in translation phase 7; it cannot be rescued by adding a suitable secondary translation unit. A call to an implicitly declared printf is translatable. There are requirements about every aspect of it. There are no requiremnts about how to translate (void *) &fn.=