[PATCH 03/13] Installed-header hygiene (BZ#20366): missing inclusions A.

[Carlos O'Donell]

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.