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] [day] [month] [year] [list]
Message-ID: <aSGmPAmCXJiv73wI@zx2c4.com>
Date: Sat, 22 Nov 2025 13:02:04 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, torvalds@...ux-foundation.org,
	ebiggers@...nel.org, kees@...nel.org, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH libcrypto v2 2/3] compiler: introduce at_least parameter
 decoration pseudo keyword

On Sat, Nov 22, 2025 at 12:53:58PM +0100, Ard Biesheuvel wrote:
> On Sat, 22 Nov 2025 at 04:08, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> >
> > On Sat, Nov 22, 2025 at 03:46:38AM +0100, Jason A. Donenfeld wrote:
> > >
> > > Saw your reply to v1 and was thinking about that. Will do. Thanks for
> > > pointing this out.
> >
> > It seems that we need to bring the brackets back, because sparse
> > won't take this either:
> >
> > int foo(int n, int a[n])
> > {
> >         return a[0]++;
> > }
> >
> > But this seems to work:
> >
> > #ifdef __CHECKER__
> > #define at_least(x)
> > #else
> > #define at_least(x) static x
> > #endif
> >
> > int foo(int n, int a[at_least(n)])
> > {
> >         return a[0]++;
> > }
> >
> 
> This is a different idiom: n is a function argument, not a compile
> time constant.
> 
> Clang and GCC both appear to permit it, but only GCC [11 or newer]
> emits a diagnostic when 'n' exceeds the size of a[]. There is also
> work ongoing to support the counted_by variable attribute for formal
> function parameters in both compilers.
> 
> So for the moment, I think we should limit this to compile time
> constants only, in which case sparse is happy too, right?

Sparse seems happy with my v3 for constants:
https://lore.kernel.org/all/20251122025510.1625066-4-Jason@zx2c4.com/

For this new idiom -- function arguments -- I think I'll look into just
fixing sparse. This seems like something useful down the line.

So I think we ought to merge v3 as-is, and then take the longer but
better road for this additional feature Herbert has brought up, by
extending sparse.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ