linux-kernel - Re: [PATCH libcrypto 1/2] array_size: introduce min_array

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251119230205.2551d7eb@pumpkin>
Date: Wed, 19 Nov 2025 23:02:05 +0000
From: david laight <david.laight@...box.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Eric Biggers <ebiggers@...nel.org>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Ard Biesheuvel <ardb@...nel.org>, Kees
 Cook <kees@...nel.org>, linux-crypto@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH libcrypto 1/2] array_size: introduce min_array_size()
 function decoration

On Wed, 19 Nov 2025 20:04:28 +0100
"Jason A. Donenfeld" <Jason@...c4.com> wrote:

> On Wed, Nov 19, 2025 at 12:31:11AM +0100, Jason A. Donenfeld wrote:
> > There's also this other approach from 2001 that the C committee I guess
> > shot down: https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_205.htm
> > It is basically:
> > 
> >     #define __at_least static
> > 
> > We could attempt to do the same with `at_least`...
> > 
> > It kind of feels like we're just inventing a language at that point
> > though.  
> 
> Actually, you know, the more this apparently terrible idea sits in my
> head, the more I like it.
> 
> Which of these is most readable to you?
> 
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[min_array_size(XCHACHA20POLY1305_NONCE_SIZE)],
>         const u8 key[min_array_size(CHACHA20POLY1305_KEY_SIZE)]);
> 
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[static XCHACHA20POLY1305_NONCE_SIZE],
>         const u8 key[static CHACHA20POLY1305_KEY_SIZE]);
> 
> bool __must_check xchacha20poly1305_decrypt(
>         u8 *dst, const u8 *src, const size_t src_len, const u8 *ad,
>         const size_t ad_len, const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
>         const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);

While bikeshedding...
I'd drop the pointless 'const' and always try to put a ptr/len pair on the same line.
So end up with:
bool __must_check xchacha20poly1305_decrypt(u8 *dst, const u8 *src, size_t src_len,
	const u8 *ad, size_t ad_len,
	const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
	const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);
or perhaps:
bool __must_check xchacha20poly1305_decrypt(u8 *dst,
	const u8 *src, size_t src_len, const u8 *ad, size_t ad_len,
	const u8 nonce[at_least XCHACHA20POLY1305_NONCE_SIZE],
	const u8 key[at_least CHACHA20POLY1305_KEY_SIZE]);
but I don't know what defines the length of '*ad'.

	David

> 
> The macro function syntax of the first one means nested bracket brain
> parsing. The second one means more `static` usage that might be
> unfamiliar. The third one actually makes it kind of clear what's up.
> It's got that weird-but-nice Objective-C-style sentence programming
> thing.
> 
> Would somebody jump in here to tell me to stop sniffing glue? I feel
> silly actually considering this, but here I am. Maybe this is actually
> an okay idea?
> 
> Jason
>