On 3/9/22 14:57, David Malcolm via Gcc wrote:
On Wed, 2022-03-09 at 13:30 -0800, Andrew Pinski wrote:
On Wed, Mar 9, 2022 at 1:25 PM David Malcolm via Gcc
<gcc@gcc.gnu.org> wrote:
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?
No, I think they are separate. The access just says these access
attributes are read only, write only, read-write or don't access what
the pointer points to; it does not say they have to be read or
written
to.
I think it is a bad idea to connect the two ideas because you could
have some cases where an argument is optional but is only read from;
or is only written to (there are many in GCC sources even).
Thanks for the clarification...
Thanks,
Andrew Pinski
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, ...))
...so that's (a) then.
I think it might be more user-friendly to be explicit about this in the
documentation, maybe something like the attached?
I agree it's worth clarifying the manual.
But I don't think there's a way to annotate a function to indicate
that it will definitely access an object (or dereference a pointer).
Attribute access just implies that it might dereference it (unless
the size is zero), and attribute nonnull that the pointer must not
be null, not that it will be dereferenced (or even that it must be
valid, although that's implied by the language and should probably
be enforced in all contexts by some other warning).
The combination of access with nonzero size and nonnull only means
that the pointer must be nonnull and point to an object with at least
size elements.
Martin
(not yet fully tested, but seems to build)
Dave
(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
