We gained __attribute__ ((access, ...)) in GCC 10: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html which identifies one of the pointer/reference arguments of a function as being accessed according to an access-mode: read_only, read_write, write_only, or none.
We also have __attribute__ ((nonnull)) to indicate that a function argument (or all of them) must be non-NULL. There doesn't seem to be a relationship between these in the implementation, but it strikes me that almost anywhere that a user might use the "access" attribute, that parameter is probably going to be required to be nonnull - though perhaps there are cases where APIs check for NULL and reject them gracefully? Might we want to somehow make __attribute__ ((access, ...)) imply __attribute__ ((nonnull))? (for non "none" access modes, perhaps?) If so, one place to implement this might be in tree.cc's get_nonnull_args, and have it add to the bitmap any arguments that have an appropriate access attribute. get_nonnull_args is used in various places: - validating builtins - in ranger_cache::block_apply_nonnull - by -Wnonnull (in pass_post_ipa_warn::execute) - by -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument; I'm tracking the failure of these last two to make use of __attribute__ ((access)) in PR analyzer/104860. So do we: (a) leave it up to the user, requiring them to specify __attribute__ ((nonnull)) in addition to __attribute__ ((access, ...)) (b) leave it up to the individual sites in GCC that currently make use of get_nonnull_args to add logic for handling __attribute__ ((access, ...)) (c) extend get_nonnull_args ? Thoughts? Dave
