This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

What is the expected behavior of attribute nonnull for C++


Consider the following test case:

struct A { bool g(int*, int*) __attribute__((nonnull (2))); };
bool A::g(int* a, int* b) {
  if (a)
    return 0;
  return this;

G++ produces the following code for this snippet:

;; Function bool A::g(int*, int*) (_ZN1A1gEPiS0_)

bool A::g(int*, int*) (this, a, b)
<bb 2>:
  return 0;


Notice how we have applied the __attribute__((nonnull (2))) to
the "a" argument, instead of "b", because G++ has added "this"
as an extra, artificial argument.  To the middle end, argument 2
of "g" is "a", not "b".

The documentation of the nonnull attribute says:

`nonnull (ARG-INDEX, ...)'
     The `nonnull' attribute specifies that some function parameters
     should be non-null pointers.  For instance, the declaration:

          extern void *
          my_memcpy (void *dest, const void *src, size_t len)
                __attribute__((nonnull (1, 2)));

     causes the compiler to check that, in calls to `my_memcpy',
     arguments DEST and SRC are non-null. 

So do we expect our users to know that they should add 1 to every
ARG-INDEX they pass?  That would make this a documentation bug.  Or
is this a "real" bug in G++, and should the compiler correct the
ARG-INDEX numbers so that the middle-end doesn't get confused?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]