This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix struct sigaltstack namespace (bug 21517)
- From: Zack Weinberg <zackw at panix dot com>
- To: libc-alpha at sourceware dot org
- Cc: Joseph Myers <joseph at codesourcery dot com>
- Date: Sat, 3 Jun 2017 10:15:03 -0400
- Subject: Re: Fix struct sigaltstack namespace (bug 21517)
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1705242232210.9182@digraph.polyomino.org.uk>
On 05/24/2017 06:32 PM, Joseph Myers wrote:
> glibc defines the stack_t type with the tag struct sigaltstack. This
> is not permitted by POSIX; sigaltstack is only reserved with file
> scope in the namespace of ordinary identifiers, not the tag namespace,
> and in the case where stack_t is obtained from ucontext.h rather than
> signal.h, it's not reserved with file scope at all.
>
> This patch removes the tag accordingly and updates uses in glibc of
> struct sigaltstack. This is similar to the removal of the "struct
> siginfo" tag a few years ago: C++ name mangling changes are an
> unavoidable consequence. A NEWS item is added to note the changed
> mangling. There is inevitably some risk of breaking builds of
> anything that relies on the struct sigaltstack name (though the first
> few hits I looked at from codesearch.debian.net generally seemed to
> involve code that could use the stack_t name conditionally, so
> depending on how they determine the conditionals they may work with
> glibc not defining the struct tag anyway).
I'm not super happy about changing C++ name mangling, but this
particular type is used rarely enough that I think we can get away with
it. Since no one has objected in over a week, this is OK.
zw