[Bug libc/29399] Wrong definition of setjmp

["zackw at panix dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29399

Zack Weinberg <zackw at panix dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zackw at panix dot com

--- Comment #6 from Zack Weinberg <zackw at panix dot com> ---
I don't think the standard is ambiguous at all.  Its wording could be improved,
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 identifier 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 define
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 refer
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.