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][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.

Alright, fair enough. So the solution you want to see is to move
stdint.h out of sysdeps, move the definition of uint_least16_t and
uint_least32_t to a definition of __*_t in bits/stdint.h, and then
define uint_least16_t, uint_least32_t, char16_t, and char32_t on the
basis of the __*_t types? Or is this overkill given that we are
assuming that stdint.h doesn't need to be system-specific? Which would
you prefer?

On Thu, Jan 28, 2016 at 5:51 PM, Joseph Myers <> wrote:
> On Thu, 28 Jan 2016, Dwight Guth wrote:
>> Would you see it as better to move stdint.h out of sysdeps, or to do
>> something similar to what's done with mbstate_t, NULL, size_t, etc by
>> defining a __need_uint_least16_t and __need_uint_least32_t and having
>> stdint.h define only a __uint_least16_t and __uint_least32_t type and
>> then exit, allowing those types to be used across an abstraction
>> boundary by uchar.h?
> I don't think we want to add more __need_* cases; if we split things out,
> it should be by adding a bits/stdint.h header that defines __*_t (and
> moving stdint.h out of sysdeps would still make sense).  Cf
> <>.
> --
> Joseph S. Myers

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