> On Oct 7, 2024, at 11:22, Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Oct 07, 2024 at 03:14:22PM +0000, Qing Zhao wrote: >>> 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. >> >> For the other attribute “alloc_size”, we have two forms, >> A. alloc_size (position) >> and >> B. alloc_size (position-1, position-2) >> >> The 2nd form is used to represent nmemb * size. >> >> Is it possible that we extend the attribute “access” similarly? >> >> Then we can use the attribute “access” consistently for this purpose? > > We could do that and express the array pointer of qsort/bsearch that way. > But there is also the function pointer case, there we don't access any bytes > (and what exactly a function pointer means depends on architecture, can be > code pointer, or can be pointer to function descriptor etc.), so we really > need to express this pointer must be non-NULL if some other argument (or > their product?) is non-0.
I have a question here (maybe a stupid question-:): do we really need to express such situation for function pointers? I cannot construct a use case for this… Qing > If one passes constant(s) to those arguments, then such checking can be > done through a warning like we warn for passing NULL to nonnull attributed > parameters right now (or not if 0), if it is non-constant, then it can be > diagnosed in sanitizers. > > Jakub >
