On Thu, Dec 02, 2021 at 10:34:23AM -0500, Rich Felker wrote: > On Mon, Nov 22, 2021 at 10:19:59PM +0000, Zack Weinberg via Libc-alpha wrote: > > On Mon, Nov 22, 2021, at 4:43 PM, Cyril Hrubis wrote: > > > This changes the __u64 and __s64 in userspace on 64bit platforms from > > > long long (unsigned) int to just long (unsigned) int in order to match > > > the uint64_t and int64_t size in userspace. > > .... > > > + > > > +#include <asm/bitsperlong.h> > > > + > > > /* > > > - * int-ll64 is used everywhere now. > > > + * int-ll64 is used everywhere in kernel now. > > > */ > > > -#include <asm-generic/int-ll64.h> > > > +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__) > > > +# include <asm-generic/int-l64.h> > > > +#else > > > +# include <asm-generic/int-ll64.h> > > > +#endif > > > > I am all for matching __uN / __sN to uintN_t / intN_t in userspace, but may I suggest the technically simpler and guaranteed-to-be-accurate > > > > /* > > - * int-ll64 is used everywhere now. > > + * int-ll64 is used everywhere in kernel now. > > + * In user space match <stdint.h>. > > */ > > +#ifdef __KERNEL__ > > # include <asm-generic/int-ll64.h> > > +#elif __has_include (<bits/types.h>) > > +# include <bits/types.h> > > +typedef __int8_t __s8; > > +typedef __uint8_t __u8; > > +typedef __int16_t __s16; > > +typedef __uint16_t __u16; > > +typedef __int32_t __s32; > > +typedef __uint32_t __u32; > > +typedef __int64_t __s64; > > +typedef __uint64_t __u64; > > +#else > > +# include <stdint.h> > > +typedef int8_t __s8; > > +typedef uint8_t __u8; > > +typedef int16_t __s16; > > +typedef uint16_t __u16; > > +typedef int32_t __s32; > > +typedef uint32_t __u32; > > +typedef int64_t __s64; > > +typedef uint64_t __u64; > > +#endif > > > > The middle clause could be dropped if we are okay with all uapi > > headers potentially exposing the non-implementation-namespace names > > defined by <stdint.h>. I do not know what the musl libc equivalent > > of <bits/types.h> is. > > We (musl) don't have an equivalent header or __-prefixed versions of > these types. > > FWIW I don't think stdint.h exposes anything that would be problematic > alongside arbitrary use of kernel headers. Also, per glibc's bits/types.h: /* * Never include this file directly; use <sys/types.h> instead. */ it's not permitted (not supported usage) to #include <bits/types.h>. So I think the above patch is wrong for glibc too. As I understand it, this is general policy for bits/* -- they're only intended to work as included by the libc system headers, not directly by something else. Rich
