[v3] uapi: Make __{u, s}64 match {u, }int64_t in userspace

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 for C code.

We cannot make the change for C++ since that would be non-backwards
compatible change and may cause possible regressions and even
compilation failures, e.g. overloaded function may no longer find a
correct match.

This allows us to use the kernel structure definitions in userspace in C
code. For example we can use PRIu64 and PRId64 modifiers in printf() to
print structure membere. Morever with this there would be no need to
redefine these structures in an libc implementations as it is done now.

Consider for example the newly added statx() syscall. If we use the
header from uapi we will get warnings when attempting to print it's
members as:

	printf("%" PRIu64 "\n", stx.stx_size);

We get:

	warning: format '%lu' expects argument of type 'long unsigned int',
	         but argument 5 has type '__u64' {aka 'long long unsigned int'}

Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
---
 include/uapi/asm-generic/types.h | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

v2: Make sure we do not break C++ applications
v3: Update commit message to explain C++ exclusion

On 6/21/22 14:03, 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 for C code.
> 
> We cannot make the change for C++ since that would be non-backwards
> compatible change and may cause possible regressions and even
> compilation failures, e.g. overloaded function may no longer find a
> correct match.
> 
> This allows us to use the kernel structure definitions in userspace in C
> code. For example we can use PRIu64 and PRId64 modifiers in printf() to
> print structure membere. Morever with this there would be no need to
> redefine these structures in an libc implementations as it is done now.
> 
> Consider for example the newly added statx() syscall. If we use the
> header from uapi we will get warnings when attempting to print it's
> members as:
> 
> 	printf("%" PRIu64 "\n", stx.stx_size);
> 
> We get:
> 
> 	warning: format '%lu' expects argument of type 'long unsigned int',
> 	         but argument 5 has type '__u64' {aka 'long long unsigned int'}
> 
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>

Acked-by: Alejandro Colomar <alx.manpages@gmail.com>

> ---
>   include/uapi/asm-generic/types.h | 11 +++++++++--
>   1 file changed, 9 insertions(+), 2 deletions(-)
> 
> v2: Make sure we do not break C++ applications
> v3: Update commit message to explain C++ exclusion
> 
> diff --git a/include/uapi/asm-generic/types.h b/include/uapi/asm-generic/types.h
> index dfaa50d99d8f..11e468a39d1e 100644

From: Cyril Hrubis 
> Sent: 21 June 2022 13:04
> 
> 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 for C code.
> 
> We cannot make the change for C++ since that would be non-backwards
> compatible change and may cause possible regressions and even
> compilation failures, e.g. overloaded function may no longer find a
> correct match.

Isn't is enough just to mention C++ name mangling?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Hi!
> > 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 for C code.
> > 
> > We cannot make the change for C++ since that would be non-backwards
> > compatible change and may cause possible regressions and even
> > compilation failures, e.g. overloaded function may no longer find a
> > correct match.
> 
> Isn't is enough just to mention C++ name mangling?

I just picked up the argument that was brought up in the discussion
about the v1 patch and used it as a concrete example. Mangling is I
guess more straightforward example of a breakage. I can change the
description if there is consensus that such description would be better.

On Tue, Jun 21, 2022 at 2:03 PM Cyril Hrubis <chrubis@suse.cz> 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 for C code.
>
> We cannot make the change for C++ since that would be non-backwards
> compatible change and may cause possible regressions and even
> compilation failures, e.g. overloaded function may no longer find a
> correct match.
>
> This allows us to use the kernel structure definitions in userspace in C
> code. For example we can use PRIu64 and PRId64 modifiers in printf() to
> print structure membere. Morever with this there would be no need to
> redefine these structures in an libc implementations as it is done now.
>
> Consider for example the newly added statx() syscall. If we use the
> header from uapi we will get warnings when attempting to print it's
> members as:
>
>         printf("%" PRIu64 "\n", stx.stx_size);
>
> We get:
>
>         warning: format '%lu' expects argument of type 'long unsigned int',
>                  but argument 5 has type '__u64' {aka 'long long unsigned int'}
>
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>

I understand the problem you are solving here, but I'm not convinced
that this is actually an overall improvement as you introduce two
similar problems in its place:

- any application that has previously used the correct %ll or %ull format
  strings for members of kernel data structures now gains a new warning

- After your patch, neither the PRIu64 nor the "%ull" format strings are
  portable across old and new kernel headers, so applications are now
  forced to add an explicit cast to 'unsigned long long' or 'uint64_t' to
  every print statement for these members if they want to guarantee a
  clean build.

Do you have an estimate of how many build time warnings in common
packages actually get fixed by your patch, compared to the number
of warnings that get introduced?

        Arnd