This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Sep 21, 2016 at 1:52 PM, Carlos O'Donell <> 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.

>> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]