Re: Variadic macros in installed headers

[Florian Weimer <fw at deneb dot enyo dot de>]

* Martin Sebor:

> The syntax of the new attribute follows the pattern of attribute
> format and I don't think it can easily be changed.  I suspected
> the variadic macros would be a problem for Glibc but I'm not sure
> how to get around it other than by providing two macros for each
> access mode.  I'm open to ideas.

__attribute__ itself gets around this because of the extra
parentheses:

  __attribute__ ((__access__ (__read_only__, 2)))

So the fallback definition can just look like this:

  #define __attribute__(x)

We could do something similar and write:

  #define __access(x) __attribute__ ((__access__ x))

  __access ((__read_only__, 2))

> One of the uses for this infrastructure that Joseph pointed out is
> VLAs (as function arguments).  I hope to add that in GCC 11 so that
> something like
>
>    void f (int a[n], unsigned n);
>
> will be automatically annotated as if it had been written like so:
>
>    __attribute__ ((access (read_write, 1, 2)))
>    void f (int a[n], unsigned n);

There is already weird syntax in this area:

  void f (unsigned n; int a[n], unsigned n);

> I'm not sure I know what you mean by C++-like pointer-pairs.

A range expressed by a pointer to its first element and a pointer one
past its last element.

I think it's possible to express this with your patch with suitable
inline function wrappers.  They would likely be simpler if there were
builtins that assert that a specific region of memory is going to be
accessed by the code below, i.e., you could write something like this:

  static inline void
  f (int *__begin, int *__end)
  {
    __builtin_access (__write_only__, __begin, __end - __begin);
    __real_f (__begin, __end);
  }

Without that, it would probably look like this:

  static inline void __attribute__ ((__access__, (__write_only__, 1, 3)))
  __f (int *__begin, int *__end, ptrdiff_t __size)
  {
    __real_f (__begin, __end);
  }

  static inline void
  f (int *__begin, int *__end)
  {
    __f (__begin, __end, __end - __begin);
  }

We probably should have two variants for __write_only__, one that says
“will write”, and one for “may write”.

Furthermore, this scheme is unfortunately incompatible with SAL:

<https://docs.microsoft.com/en-us/visualstudio/code-quality/understanding-sal>