This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/13] Installed-header hygiene (BZ#20366): missing inclusions A.
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Wed, 21 Sep 2016 14:43:27 -0400
- Subject: Re: [PATCH 03/13] Installed-header hygiene (BZ#20366): missing inclusions A.
- Authentication-results: sourceware.org; auth=none
- References: <20160830011645.25769-1-zackw@panix.com> <20160830011645.25769-2-zackw@panix.com> <20160830011645.25769-3-zackw@panix.com> <20160830011645.25769-4-zackw@panix.com> <cf5db8e3-19cf-a374-c6d4-3145ab31989e@redhat.com> <CAKCAbMhhDPWxphZ2HdmjwcCP3Hgg07tuMk9Sepd+5iHKdpmaOQ@mail.gmail.com>
On 09/21/2016 02:22 PM, Zack Weinberg wrote:
> On Wed, Sep 21, 2016 at 1:52 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 08/29/2016 09:16 PM, Zack Weinberg wrote:
>>> These are all fallout from the change from u_intNN_t to uintNN_t; a
>>> number of headers now need to include <stdint.h> to pick up those
>>> types. It is possible that __uintNN_t should be used instead.
>>
>> Why should __uintNN_t ever be used? At a minimum the uintNN_t types
>> should be available regardless of whatever mode you are being compiled in?
>
> It might be inappropriate for some of these headers to (behave as-if
> they) include <stdint.h>. Joseph says that existing conform/ tests
> cover this from a standards-compliance perspective, but it is my
> understanding that net/* and netinet/* headers are not very well
> standardized, so we might want to think about whether we should go to
> extra effort here.
Thanks for the clarification.
Given the underspecified nature of those headers I don't see that we need
to worry. If someone comes back and has a valid complaint we could always
do a further cleanup?
>>> Some of these files directly included <features.h> and/or
>>> <sys/cdefs.h>, which I removed, as the style generally seems to be to
>>> let <sys/types.h> do that for us. One file included <asm/types.h>
>>> gratuitously.
>>
>> Are you certain that was safe? I would be worried about arbitrarily
>> removing those headers without a deeper analysis.
>
> sys/types.h unconditionally includes features.h, and features.h
> unconditionally includes sys/cdefs.h.
>
> None of the definitions in asm/types.h were required by the file that
> was including it.
>
> I will do a check for unchanged installed libraries as discussed elsewhere.
Belt-and-suspenders ;-)
--
Cheers,
Carlos.