Hi Bruno, On Mon, Dec 15, 2025 at 11:41:31PM +0100, Bruno Haible wrote: > Alejandro Colomar wrote: > > You could ask GCC to implement Clang's [[gnu::nonnull]] which goes > > inside the parameter list. That would remove the error-prone concerns. > > > > #define NONNULL [[gnu::nonnull]] > > > > int foo(int n, NONNULL char buf[n]); > > > > I'm pretty sure you wouldn't call that ugly or error-prone. > > I definitely agree with you here, Alejandro. I find
:) > extern nullable expression_t > create_literal_expression (nonnull literal_t literal, > nullable annotation_t annotation, > size_t nattributes, > nonnull attribute_t > attributes[/*nattributes*/]); > > easier to read and understand than > > extern expression_t > create_literal_expression (literal_t literal, > annotation_t annotation, > size_t nattributes, > attribute_t attributes[/*nattributes*/]) > __attribute__ ((__nonnull__ (1, 4))); > > While I understand that GCC's __attribute__ syntax, attached to the entire > function > declaration, is more powerful when it comes to describing constraints between > parameters > (such as with the memcpy() function after n3322), in the vast majority of the > uses n3322 was a partial mistake, IMO, precisely because it breaks these attributes. I voted against it. I think memcpy(3) should not accept a null pointer. I think it was a good thing to avoid the UB, but diagnostics should remain. That's why we need a nullability qualifier, _Optional, which works like const, in that it allows a null pointer without UB, but it still diagnoses it. > of 'nonnull' the attribute describes a single parameter or independent > parameters, > and for these it is a 500% win in legibility to be able to put it _into_ the > parameter list. Have a lovely night! Alex -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
