From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F14303858C51; Thu, 28 Jul 2022 19:38:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F14303858C51 From: "zackw at panix dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/29399] Wrong definition of setjmp Date: Thu, 28 Jul 2022 19:38:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: zackw at panix dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 19:38:59 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29399 Zack Weinberg changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zackw at panix dot com --- Comment #6 from Zack Weinberg --- I don't think the standard is ambiguous at all. Its wording could be impro= ved, but there's only one interpretation that makes sense. Since at least C11, section 7.1.3p2 reads in part > If the program declares or defines an identifier in a context in which it= is reserved (other than as allowed by 7.1.4), **or defines a reserved iden= tifier as a macro name**, the behavior is undefined. The clause set off by double asterisks doesn't make any sense unless "a reserved identifier" is understood broadly: if the program defines an identifier that is reserved *in any context* as macro name, the behavior is undefined. To put it another way, I believe the intent of this sentence is that any identifier that is reserved in any phase-7 context is also, unconditionally, reserved for use as a macro name. --- The program in comment 4 defines a reserved identifier as a macro name, and= is therefore invalid. The program in comment 0, on the other hand, doesn't de= fine any macros; it defines a *local variable*, using a name that is reserved for use by the implementation *only* at file scope. This clashes with setjmp.h assuming that the `_setjmp` in the expansion of the `setjmp` macro will ref= er to a global symbol. I think this *is* a bug in glibc's setjmp.h. The thing it's doing with macros should be done with __REDIRECT instead. --=20 You are receiving this mail because: You are on the CC list for the bug.=