Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <YZvIlz7J6vOEY+Xu@yuki>
References: <YZvIlz7J6vOEY+Xu@yuki>
To:     Cyril Hrubis <chrubis@suse.cz>
Cc:     dhowells@redhat.com, linux-kernel@vger.kernel.org,
        linux-api@vger.kernel.org, ltp@lists.linux.it,
        libc-alpha@sourceware.org, linux-arch@vger.kernel.org,
        arnd@arndb.de
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1618288.1637686052.1@warthog.procyon.org.uk>
Date:   Tue, 23 Nov 2021 16:47:32 +0000
Message-ID: <1618289.1637686052@warthog.procyon.org.uk>
Precedence: bulk

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.

Can you guarantee this won't break anything in userspace?  Granted the types
*ought* to be the same size, but anyone who's written code on the basis that
these are "(unsigned) long long int" may suddenly get a bunch of warnings
where they didn't before from the C compiler.  Anyone using C++, say, may find
their code no longer compiles because overloaded function matching no longer
finds a correct match.

Also, whilst your point about PRIu64 and PRId64 modifiers in printf() is a
good one, it doesn't help someone whose compiler doesn't support that (I don't
know if anyone's likely to encounter such these days).  At the moment, I think
a user can assume that %llu will work correctly both on 32-bit and 64-bit on
all arches, but you're definitely breaking that assumption.

David