This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Rename struct ucontext tag (bug 21457)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 13 Jun 2017 08:49:34 +0200
- Subject: Re: Rename struct ucontext tag (bug 21457)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5493561B85
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5493561B85
- References: <alpine.DEB.2.20.1706122358120.17570@digraph.polyomino.org.uk>
On 06/13/2017 01:58 AM, Joseph Myers wrote:
> The ucontext_t type has a tag struct ucontext. As with previous such
> issues for siginfo_t and stack_t, this tag is not permitted by POSIX
> (is not in a reserved namespace), and so namespace conformance means
> breaking C++ name mangling for this type.
I don't see a reference in Fedora to a _Z*ucontext* symbol, so I don't
expect any ABI problems.
> In this case, the type does need to have some tag rather than just a
> typedef name, because it includes a pointer to itself. This patch
> uses struct ucontext_t as the new tag, so the type is mangled as
> ucontext_t (the POSIX *_t reservation applies in all namespaces, not
> just the namespace of ordinary identifiers). Another reserved name
> such as struct __ucontext could of course be used.
How widely known is the reserved nature of _t names? Maybe the __
prefix would communicate better that this is an internal name? Although
I assume we will never change it again, so applications referencing the
new name should not face any future problems.
Thanks,
Florian