Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220621120355.2903-1-chrubis@suse.cz>
In-Reply-To: <20220621120355.2903-1-chrubis@suse.cz>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Thu, 23 Jun 2022 09:48:13 +0200
Message-ID: <CAK8P3a2J5k2ub6TNu9qDympdWEdQkqpbL_SqAznpwaQa+S9kXQ@mail.gmail.com>
Subject: Re: [PATCH v3] uapi: Make __{u,s}64 match {u,}int64_t in userspace
To:     Cyril Hrubis <chrubis@suse.cz>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>,
        GNU C Library <libc-alpha@sourceware.org>,
        Arnd Bergmann <arnd@arndb.de>, LTP List <ltp@lists.linux.it>,
        David Laight <David.Laight@aculab.com>,
        Zack Weinberg <zack@owlfolio.org>,
        David Howells <dhowells@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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