On Fri, Oct 04, 2024 at 12:42:24AM +0200, Florian Weimer wrote:
> * Joseph Myers:
>
> > The real question is how to achieve optimal warnings in the absence of the
> > attribute. Should we have a variant of the nonnull attribute that warns
> > for NULL arguments but without optimizing based on them?
>
> I think attribute access already covers part of it:
>
> #include <stddef.h>
> void read_array (void *, size_t) __attribute__ ((access (read_only, 1, 2)));
> void
> f (void)
> {
> read_array (NULL, 0); // No warning.
> read_array (NULL, 1); // Warning.
> }
>
> It does not work for functions like strndup that support both string
> arguments (of any length) and array arguments of a specified size.
> The read_only variant requires an initialized array of the specified
> length.
access attribute can't deal with various other things.
Consider the qsort case. My understanding was that the paper is making
typedef int (*cmpfn) (const void *, const void *);
qsort (NULL, 0, 1, (cmpfn) NULL);
valid (but is
qsort (NULL, 1, 0, (cmpfn) NULL);
still invalid?).
How do you express that with access attribute, which can only have 1 size
argument? The accessed memory for the read/write pointee of the first
argument has nmemb * size parameter bytes size.
And using access attribute for function pointers doesn't work, there is
no data to be read/written there, just code.
Guess some of the nonnull cases could be replaced by access attribute
if we clarify the documentation that if SIZE_INDEX is specified and that
argument is non-zero then the pointer has to be non-NULL, and teach
sanitizers etc. to sanitize those.
For the rest, perhaps we need some nonnull_if_nonzero argument
which requires that the parameter identified by the first attribute
argument must be pointer which is non-NULL if the parameter identified
by the second attribute argument is non-zero.
And get clarified the qsort/bsearch cases whether it is about just
nmemb == 0 or nmemb * size == 0.
Jakub
