Hi Paul, On Sun, Dec 14, 2025 at 10:05:29AM -0800, Paul Eggert wrote: > On 2025-12-14 02:30, Alejandro Colomar wrote: > > On Sat, Dec 13, 2025 at 09:14:12PM -0800, Paul Eggert wrote: > > > #ifdef __STDC_NO_VLA__ > > > # define VLA_ELEMS(n) > > > #else > > > # define VLA_ELEMS(n) static n > > > #endif > > > > You could use 'n' instead of 'static n'. I expect that would work > > always. > > Yes it'd compile and run, but it wouldn't mean the same thing. Thien-Thi > wanted the 'static n' meaning.
What wanted Thien-Thi exactly? If they wanted the non-null implications of [static n], it can use [n] combined with [[gnu::nonnull()]]. I see no reasons to use [static n] ever. > > We already know how dangerous [[gnu::nonnull()]] is, so 'static' should > > be considered just as dangerous. > > How is [[gnu::nonnull()]] more dangerous than attributes like GNU C's > __attribute__ ((__nonnull__ ())) that Gnulib uses all the time? It's exactly the same. [[gnu::nonnull()]] is the C23-conforming way to spell __attribute__ ((__nonnull__ ())). > Yes, there are dangers in using these attributes. The thing that bugs me the > most occurs in functions like execl where for compatibility with traditional > dynamic checking for null pointers Gnulib must jump through a hoop to also > do static checking. (I wish we'd never done the dynamic checking, as the > static checking is better.) > > But there are also dangers in not using these attributes, and in practice > the former dangers seem less than the latter. If you use -fno-delete-null-pointer-checks, the dangers of [[gnu::nonnull()]] vanish, and you only get the good parts of it. > (Hey, it's C! People *expect* it to be dangerous! :-) I actually expect C to be quite safe. I might be crazy, though. :-) Have a lovely night! Alex -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
