This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 07/13] Installed-header hygiene (BZ#20366): stack_t.
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>, libc-alpha at sourceware dot org
- Cc: joseph at codesourcery dot com
- Date: Wed, 21 Sep 2016 15:50:44 -0400
- Subject: Re: [PATCH 07/13] Installed-header hygiene (BZ#20366): stack_t.
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On 08/29/2016 09:16 PM, Zack Weinberg wrote:
> This is long and repetitive because it touches a whole bunch of
> sysdeps headers.
> sys/ucontext.h unconditionally uses stack_t, and it does not make
> sense to change that. But signal.h only declares stack_t under
> __USE_XOPEN_EXTENDED || __USE_XOPEN2K8. The actual definition is already
> in a bits header, bits/sigstack.h, but that header insists on only being
> included by signal.h, so we have to change that as well as all of the
> sys/ucontext.h variants. (Some but not all variants of bits/sigcontext.h,
> which sys/ucontext.h may also need, had already received this adjustment;
> for consistency, I made them all the same, even if that's not strictly
> necessary in some configurations.) bits/sigcontext.h and bits/sigstack.h
> also all need to receive multiple inclusion guards (why were we being
> sloppy about that?)
LGTM. This is a good looking cleanup.