From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9820F3858D28; Tue, 2 Apr 2024 21:37:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9820F3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712093879; bh=60+4oMuT79ImAt8wNWnrfFX8O4hnqgCRbixkUYoO8cA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C2Cq3Fn2edhMJcB6RqZUkc4+J/X+BUw5TmxqYtA+voRM+Wt4Y5Cm6oxZm1LTsVa35 p6uQkV+wspDfLlZ18et+tGa9up/PsoMt0Fi+ONc1NnqgEifH6MmLOnJkEn2xRNPXcS tYREXDg81mkW1o0+9qWzBeZdmIx05QSiplc0l9Ms= 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 21:37:59 +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 #18 from Harald van Dijk --- (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. The DRs I referenced include ones where type errors have explicitly been st= ated not to render behaviour undefined. DR 132 (C90): /* No headers included */ int checkup() { /* Case 1 */ if (0) printf("Printing.\n"); /* Case 2 */ return 2 || 1 / 0; }=20 Response: "The Response to Defect Report #109 addresses this issue. The translation unit must be successfully translated." This, despite the fact that it implicitly declares as int(*)(), which is incompatible with the type it is meant to be declared as. The distinction you see between type errors and non-type errors is not one = that I believe is supported by previous DR responses. > We wouldn't say that >=20 > void f(void) { "abc" / "def"; } >=20 > 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 requir= es > a diagnostic. My position is that it is *only* because this violates a constraint that th= is cannot be part of a strictly conforming program, even if never called, as f= ar as standard C is concerned. That is why implementations are allowed to reje= ct it without program flow analysis. > Anyway, this is all moot because this bugzilla is about GNU C, which has = the > extension. The behavior is locally defined. Sure, I'm happy to put that aside if it becomes irrelevant to the bug. > We would like NOT to have a diagnostic under -Wpedantic, so we are on the > same page. >=20 > 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. >=20 > There is nothing wrong with the diagnostic, but it should be uncoupled fr= om > -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). Agreed that having the warning is useful. If 'gcc -std=3Dc99 -pedantic-erro= rs' emits a warning for this, regardless of whether it is enabled by default, t= hat is fine, and that does not prevent it from being a valid implementation of = the 'c99' utility.=