Re: [RFC PATCH] libcrypto/chachapoly: Use strict typing for fixed size array arguments

[Daniel Thompson <danielt@kernel.org>]

On Tue, Dec 02, 2025 at 02:12:47AM +0100, Alejandro Colomar wrote:
> Hi,
>
> Jason said:
> > On Sat, Nov 15, 2025 at 09:11:31AM -0800, Linus Torvalds wrote:
> > > So *if* we end up using this syntax more widely, I suspect we'd want
> > > to have a macro that makes the semantics more obvious, even if it's
> > > something silly and trivial like
> > >
> > >    #define min_array_size(n) static n
> > >
> > > just so that people who aren't familiar with that crazy syntax
> > > understand what it means.
> >
> > Oh that's a good suggestion. I'll see if I can rig that up and send
> > something.
>
> Be careful about [static n].  It has implications that you're probably
> not aware of.  Also, it doesn't have some implications you might expect
> from it.
>
> -  [static n] on an argument implies __attribute__((nonnull())) on that
>    argument; it means that the argument can't be null.  You may want to
>    make sure you're using -fno-delete-null-pointer-checks if you use
>    [static n].
>
> -  [static n] implies that n>0.  You should make sure that n>0, or UB
>    would be triggered.
>
> -  [n] means two promises traditionally:
>    -  The caller will provide at least n elements.
>    -  The callee will use no more than n elements.
>    However, [static n] only carries the first promise.  According to
>    ISO C, the callee may access elements beyond that.

This description implies that [n] carries promises that [static n] does
not. However you are comparing the "traditional" behaviour (that is
well beyond the scope of the standard) on one side with ISO C behaviour
on the other.

It makes sense to compare ISO C behavior for [n] (where neither of the
above promises applies) with ISO C behaviour for [static n]...


>    GCC, as a quality implementation, enforces the second promise too,
>    but this is not portable; you should make sure that all supported
>    compilers enforces that as an extension.

... and equally it makes sense to compare the gcc/clang warnings for
[n] versus [static n] as recommended here.

However it should not be motivated by [static n] carrying few promises
than [n], especially given gcc/clang's enforcement of the promises is
a best effort static check that won't cover all cases anyway.


Daniel.