The value of __BITS_PER_LONG from architecture-specific logic should
always match the generic one if that is available. It should also match
the actual C type 'long'.

Mismatches can happen for example when building the compat vDSO. Either
during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
when mismatched CHECKFLAGS are inherited from the kernel build.

Add some consistency checks which detect such issues early and clearly.
The tests are added to the UAPI header to make sure it is also used when
building the vDSO as that is not supposed to use regular kernel headers.

The kernel-interal BITS_PER_LONG is not checked as it is derived from
CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
deactivated check in include/asm-generic/bitsperlong.h.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
index fadb3f857f28..9d762097ae0c 100644
--- a/include/uapi/asm-generic/bitsperlong.h
+++ b/include/uapi/asm-generic/bitsperlong.h
@@ -28,4 +28,18 @@
 #define __BITS_PER_LONG_LONG 64
 #endif
 
+/* Consistency checks */
+#ifdef __KERNEL__
+#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
+#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
+#error Inconsistent word size. Check uapi/asm/bitsperlong.h
+#endif
+#endif
+
+#ifndef __ASSEMBLER__
+_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
+	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
+#endif
+#endif /* __KERNEL__ */
+
 #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */

-- 
2.52.0

On 2026-01-15 23:40, Thomas Weißschuh wrote:
> The value of __BITS_PER_LONG from architecture-specific logic should
> always match the generic one if that is available. It should also match
> the actual C type 'long'.
> 
> Mismatches can happen for example when building the compat vDSO. Either
> during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> when mismatched CHECKFLAGS are inherited from the kernel build.
> 
> Add some consistency checks which detect such issues early and clearly.
> The tests are added to the UAPI header to make sure it is also used when
> building the vDSO as that is not supposed to use regular kernel headers.
> 
> The kernel-interal BITS_PER_LONG is not checked as it is derived from
> CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> deactivated check in include/asm-generic/bitsperlong.h.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> index fadb3f857f28..9d762097ae0c 100644
> --- a/include/uapi/asm-generic/bitsperlong.h
> +++ b/include/uapi/asm-generic/bitsperlong.h
> @@ -28,4 +28,18 @@
>  #define __BITS_PER_LONG_LONG 64
>  #endif
>  
> +/* Consistency checks */
> +#ifdef __KERNEL__
> +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> +#endif
> +#endif
> +
> +#ifndef __ASSEMBLER__
> +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
> +#endif
> +#endif /* __KERNEL__ */
> +
>  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> 

Do we actually support any compilers which *don't* define __SIZEOF_LONG__?

	-hpa

On Mon, Jan 19, 2026 at 07:33:13AM -0800, H. Peter Anvin wrote:
> On 2026-01-15 23:40, Thomas Weißschuh wrote:
> > The value of __BITS_PER_LONG from architecture-specific logic should
> > always match the generic one if that is available. It should also match
> > the actual C type 'long'.
> > 
> > Mismatches can happen for example when building the compat vDSO. Either
> > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > when mismatched CHECKFLAGS are inherited from the kernel build.
> > 
> > Add some consistency checks which detect such issues early and clearly.
> > The tests are added to the UAPI header to make sure it is also used when
> > building the vDSO as that is not supposed to use regular kernel headers.
> > 
> > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > deactivated check in include/asm-generic/bitsperlong.h.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > index fadb3f857f28..9d762097ae0c 100644
> > --- a/include/uapi/asm-generic/bitsperlong.h
> > +++ b/include/uapi/asm-generic/bitsperlong.h
> > @@ -28,4 +28,18 @@
> >  #define __BITS_PER_LONG_LONG 64
> >  #endif
> >  
> > +/* Consistency checks */
> > +#ifdef __KERNEL__
> > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > +#endif
> > +#endif
> > +
> > +#ifndef __ASSEMBLER__
> > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
> > +#endif
> > +#endif /* __KERNEL__ */
> > +
> >  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> > 
> 
> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?

When building the kernel not. I used this pattern because it is used
further up in the file. There it makes sense as it is actually a userspace
header which needs to support all kinds of compilers.
But this new check is gated behind __KERNEL__ anyways...
For the next revision I will move it into the regular kernel-internal
bitsperlong.h. That will be less confusing and still handle the vDSO build,
due to the way our header hierarchy works.


Thomas

On 2026-01-19 07:39, Thomas Weißschuh wrote:
>>
>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?
> 
> When building the kernel not. I used this pattern because it is used
> further up in the file. There it makes sense as it is actually a userspace
> header which needs to support all kinds of compilers.
> But this new check is gated behind __KERNEL__ anyways...
> For the next revision I will move it into the regular kernel-internal
> bitsperlong.h. That will be less confusing and still handle the vDSO build,
> due to the way our header hierarchy works.
> 

The point is that we can simply do:

#define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)

... and it will always be consistent.

	-hpa

On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote:
> On 2026-01-19 07:39, Thomas Weißschuh wrote:
>>>
>>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?
>> 
>> When building the kernel not. I used this pattern because it is used
>> further up in the file. There it makes sense as it is actually a userspace
>> header which needs to support all kinds of compilers.
>> But this new check is gated behind __KERNEL__ anyways...
>> For the next revision I will move it into the regular kernel-internal
>> bitsperlong.h. That will be less confusing and still handle the vDSO build,
>> due to the way our header hierarchy works.
>> 
>
> The point is that we can simply do:
>
> #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)
>
> ... and it will always be consistent.

We have discussed this before, but decided it was too early to
assume that userspace compilers are recent enough for that.
According to godbolt.org, gcc-4.1 lacks __SIZEOF_LONG__ while
gcc-4.4 has it, as do all versions of clang. Not sure what other
compilers one may encounter using Linux kernel headers.

     Arnd

On Mon, 19 Jan 2026 22:39:53 +0100
"Arnd Bergmann" <arnd@arndb.de> wrote:

> On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote:
> > On 2026-01-19 07:39, Thomas Weißschuh wrote:  
> >>>
> >>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?  
> >> 
> >> When building the kernel not. I used this pattern because it is used
> >> further up in the file. There it makes sense as it is actually a userspace
> >> header which needs to support all kinds of compilers.
> >> But this new check is gated behind __KERNEL__ anyways...
> >> For the next revision I will move it into the regular kernel-internal
> >> bitsperlong.h. That will be less confusing and still handle the vDSO build,
> >> due to the way our header hierarchy works.
> >>   
> >
> > The point is that we can simply do:
> >
> > #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)
> >
> > ... and it will always be consistent.  
> 
> We have discussed this before, but decided it was too early to
> assume that userspace compilers are recent enough for that.
> According to godbolt.org, gcc-4.1 lacks __SIZEOF_LONG__ while
> gcc-4.4 has it, as do all versions of clang. Not sure what other
> compilers one may encounter using Linux kernel headers.

For instance MSVC doesn't define __SIZEOF_LONG__ or __x86_64__.
Unlikely to be used, but...

So you can use __SIZEOF_LONG__ if it is defined, if not hunt for
something else (possible just fixed in the installed headers).
But in the latter case (at least) a compile-time check that the
value is correct makes sense.
And that can be done portably - probable with a negative array size.

	David

> 
>      Arnd
> 

On January 20, 2026 2:03:31 AM PST, David Laight <david.laight.linux@gmail.com> wrote:
>On Mon, 19 Jan 2026 22:39:53 +0100
>"Arnd Bergmann" <arnd@arndb.de> wrote:
>
>> On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote:
>> > On 2026-01-19 07:39, Thomas Weißschuh wrote:  
>> >>>
>> >>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?  
>> >> 
>> >> When building the kernel not. I used this pattern because it is used
>> >> further up in the file. There it makes sense as it is actually a userspace
>> >> header which needs to support all kinds of compilers.
>> >> But this new check is gated behind __KERNEL__ anyways...
>> >> For the next revision I will move it into the regular kernel-internal
>> >> bitsperlong.h. That will be less confusing and still handle the vDSO build,
>> >> due to the way our header hierarchy works.
>> >>   
>> >
>> > The point is that we can simply do:
>> >
>> > #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)
>> >
>> > ... and it will always be consistent.  
>> 
>> We have discussed this before, but decided it was too early to
>> assume that userspace compilers are recent enough for that.
>> According to godbolt.org, gcc-4.1 lacks __SIZEOF_LONG__ while
>> gcc-4.4 has it, as do all versions of clang. Not sure what other
>> compilers one may encounter using Linux kernel headers.
>
>For instance MSVC doesn't define __SIZEOF_LONG__ or __x86_64__.
>Unlikely to be used, but...
>
>So you can use __SIZEOF_LONG__ if it is defined, if not hunt for
>something else (possible just fixed in the installed headers).
>But in the latter case (at least) a compile-time check that the
>value is correct makes sense.
>And that can be done portably - probable with a negative array size.
>
>	David
>
>> 
>>      Arnd
>> 
>
>

If it doesn't define __x86_64__ it isn't API compliant at all, so it doesn't make any sense to talk about it. 

The most portable way to do it in standard C is to use <limits.h>, but that of course has the header pollution problem.

On Fri, 16 Jan 2026 08:40:27 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:

> The value of __BITS_PER_LONG from architecture-specific logic should
> always match the generic one if that is available. It should also match
> the actual C type 'long'.
> 
> Mismatches can happen for example when building the compat vDSO. Either
> during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> when mismatched CHECKFLAGS are inherited from the kernel build.
> 
> Add some consistency checks which detect such issues early and clearly.
> The tests are added to the UAPI header to make sure it is also used when
> building the vDSO as that is not supposed to use regular kernel headers.
> 
> The kernel-interal BITS_PER_LONG is not checked as it is derived from
> CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> deactivated check in include/asm-generic/bitsperlong.h.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> index fadb3f857f28..9d762097ae0c 100644
> --- a/include/uapi/asm-generic/bitsperlong.h
> +++ b/include/uapi/asm-generic/bitsperlong.h
> @@ -28,4 +28,18 @@
>  #define __BITS_PER_LONG_LONG 64
>  #endif
>  
> +/* Consistency checks */
> +#ifdef __KERNEL__
> +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> +#endif
> +#endif
> +
> +#ifndef __ASSEMBLER__
> +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");

nak...

You can't assume the compiler has _Static_assert().
All the ones that do probably define __SIZEOF_LONG__.
You could use something 'old-school' like:
typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];

	David

> +#endif
> +#endif /* __KERNEL__ */
> +
>  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> 

On Mon, Jan 19, 2026 at 10:06:19AM +0000, David Laight wrote:
> On Fri, 16 Jan 2026 08:40:27 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> 
> > The value of __BITS_PER_LONG from architecture-specific logic should
> > always match the generic one if that is available. It should also match
> > the actual C type 'long'.
> > 
> > Mismatches can happen for example when building the compat vDSO. Either
> > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > when mismatched CHECKFLAGS are inherited from the kernel build.
> > 
> > Add some consistency checks which detect such issues early and clearly.
> > The tests are added to the UAPI header to make sure it is also used when
> > building the vDSO as that is not supposed to use regular kernel headers.
> > 
> > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > deactivated check in include/asm-generic/bitsperlong.h.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > index fadb3f857f28..9d762097ae0c 100644
> > --- a/include/uapi/asm-generic/bitsperlong.h
> > +++ b/include/uapi/asm-generic/bitsperlong.h
> > @@ -28,4 +28,18 @@
> >  #define __BITS_PER_LONG_LONG 64
> >  #endif
> >  
> > +/* Consistency checks */
> > +#ifdef __KERNEL__
> > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > +#endif
> > +#endif
> > +
> > +#ifndef __ASSEMBLER__
> > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
> 
> nak...
> 
> You can't assume the compiler has _Static_assert().
> All the ones that do probably define __SIZEOF_LONG__.
> You could use something 'old-school' like:
> typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];

This is only used when building the kernel, it never actually reaches
userspace. And all supported compilers for the kernel do have _Static_assert().
As indicated by other users of _Static_assert() we have elsewhere in the tree.

> 
> 	David
> 
> > +#endif
> > +#endif /* __KERNEL__ */
> > +
> >  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */

On Mon, 19 Jan 2026 11:13:08 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:

> On Mon, Jan 19, 2026 at 10:06:19AM +0000, David Laight wrote:
> > On Fri, 16 Jan 2026 08:40:27 +0100
> > Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> >   
> > > The value of __BITS_PER_LONG from architecture-specific logic should
> > > always match the generic one if that is available. It should also match
> > > the actual C type 'long'.
> > > 
> > > Mismatches can happen for example when building the compat vDSO. Either
> > > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > > when mismatched CHECKFLAGS are inherited from the kernel build.
> > > 
> > > Add some consistency checks which detect such issues early and clearly.
> > > The tests are added to the UAPI header to make sure it is also used when
> > > building the vDSO as that is not supposed to use regular kernel headers.
> > > 
> > > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > > deactivated check in include/asm-generic/bitsperlong.h.
> > > 
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > > ---
> > >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > > index fadb3f857f28..9d762097ae0c 100644
> > > --- a/include/uapi/asm-generic/bitsperlong.h
> > > +++ b/include/uapi/asm-generic/bitsperlong.h
> > > @@ -28,4 +28,18 @@
> > >  #define __BITS_PER_LONG_LONG 64
> > >  #endif
> > >  
> > > +/* Consistency checks */
> > > +#ifdef __KERNEL__
> > > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > > +#endif
> > > +#endif
> > > +
> > > +#ifndef __ASSEMBLER__
> > > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");  
> > 
> > nak...
> > 
> > You can't assume the compiler has _Static_assert().
> > All the ones that do probably define __SIZEOF_LONG__.
> > You could use something 'old-school' like:
> > typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];  
> 
> This is only used when building the kernel, it never actually reaches
> userspace. And all supported compilers for the kernel do have _Static_assert().
> As indicated by other users of _Static_assert() we have elsewhere in the tree.

Don't you need a check that it isn't wrong on a user system?
Which is what I thought it was doing.

The earlier check can also just be:

#if defined(__SIZEOF_LONG__) && __BITS_PER_LONG != 8 * __SIZEOF_LONG__
#error Inconsistent word size. Check uapi/asm/bitsperlong.h
#endif

	David

> 
> > 
> > 	David
> >   
> > > +#endif
> > > +#endif /* __KERNEL__ */
> > > +
> > >  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */  

On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:
> On Mon, 19 Jan 2026 11:13:08 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> 
> > On Mon, Jan 19, 2026 at 10:06:19AM +0000, David Laight wrote:
> > > On Fri, 16 Jan 2026 08:40:27 +0100
> > > Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> > >   
> > > > The value of __BITS_PER_LONG from architecture-specific logic should
> > > > always match the generic one if that is available. It should also match
> > > > the actual C type 'long'.
> > > > 
> > > > Mismatches can happen for example when building the compat vDSO. Either
> > > > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > > > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > > > when mismatched CHECKFLAGS are inherited from the kernel build.
> > > > 
> > > > Add some consistency checks which detect such issues early and clearly.
> > > > The tests are added to the UAPI header to make sure it is also used when
> > > > building the vDSO as that is not supposed to use regular kernel headers.
> > > > 
> > > > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > > > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > > > deactivated check in include/asm-generic/bitsperlong.h.
> > > > 
> > > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > > > ---
> > > >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > > > index fadb3f857f28..9d762097ae0c 100644
> > > > --- a/include/uapi/asm-generic/bitsperlong.h
> > > > +++ b/include/uapi/asm-generic/bitsperlong.h
> > > > @@ -28,4 +28,18 @@
> > > >  #define __BITS_PER_LONG_LONG 64
> > > >  #endif
> > > >  
> > > > +/* Consistency checks */
> > > > +#ifdef __KERNEL__
> > > > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > > > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > > > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > > > +#endif
> > > > +#endif
> > > > +
> > > > +#ifndef __ASSEMBLER__
> > > > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > > > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");  
> > > 
> > > nak...
> > > 
> > > You can't assume the compiler has _Static_assert().
> > > All the ones that do probably define __SIZEOF_LONG__.
> > > You could use something 'old-school' like:
> > > typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];  
> > 
> > This is only used when building the kernel, it never actually reaches
> > userspace. And all supported compilers for the kernel do have _Static_assert().
> > As indicated by other users of _Static_assert() we have elsewhere in the tree.
> 
> Don't you need a check that it isn't wrong on a user system?
> Which is what I thought it was doing.

Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
being tested here. If they work in the kernel build I assume they also work
in userspace.

> The earlier check can also just be:
> 
> #if defined(__SIZEOF_LONG__) && __BITS_PER_LONG != 8 * __SIZEOF_LONG__
> #error Inconsistent word size. Check uapi/asm/bitsperlong.h
> #endif

The if defined(__SIZEOF_LONG__) is also unnecessary as that is always present
with the supported kernel compilers.  So we can drop one level of ifdeffery.

Testing __CHAR_BIT__ == 8 would again test the compiler implementation and not
the UAPI headers, so I'd rather not do it. Using __CHAR_BIT__ in the test is
done for consistency with the generic implementation.


Thomas