linux-kernel - Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Nov 2021 16:47:32 +0000
From:   David Howells <dhowells@...hat.com>
To:     Cyril Hrubis <chrubis@...e.cz>
Cc:     dhowells@...hat.com, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org, ltp@...ts.linux.it,
        libc-alpha@...rceware.org, linux-arch@...r.kernel.org,
        arnd@...db.de
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace

Cyril Hrubis <chrubis@...e.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