On 7 May 2015 at 19:51, Martin Uecker <uec...@eecs.berkeley.edu> wrote: > Am Mon, 04 May 2015 18:28:49 +0200 > schrieb Manuel López-Ibáñez <lopeziba...@gmail.com>: > >> On 04/05/15 07:40, Martin Uecker wrote: >> > >> > BTW: Why is 'nonnull' a function attribute and not something >> > which can be attached to pointer types? >> >> I think this is something wanted for a long time: >> >> https://gcc.gnu.org/ml/gcc/2006-04/msg00550.html >> >> but nobody has implemented it yet. Perhaps there was some technical hurdle in >> the past, probably long gone. >> >> Clang has implemented this variation already sometime ago: >> >> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140203/098497.html >> >> so there is a precedent. > > Interestingly, this leads to an incompatibility between gcc and > clang. Consider this: > > void foo(__attribute__((nonnull)) int *a)
Good catch! Perhaps this applies? "At present, the first parameter in a function prototype must have some type specifier that is not an attribute specifier; this resolves an ambiguity in the interpretation of void f(int (__attribute__((foo)) x))" https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax But I don't understand the example given in the docs. In any case, what would be the syntax (in Clang) for specifying that '*a' is a nonnull function? Clang also implements the gnu-style nonnull attribute, hence they probably have some incompatibility with previous versions of itself (the new syntax is only one year old). In general, my impression (Jason, Joseph, please correct me if I'm wrong here) is that it is ok to accept attributes in a place that was ignored previously, and to ignore attributes if the placement was working by luck and not documented (hopefully with a warning, which we are missing above?), but it is definitely not ok to ignore attributes that were documented to work before. It is definitely a goal to make the placement consistent between C and C++ and to satisfy the rules of C++ as to where the attributes can appear (but being permissive as to where they cannot appear). Thus, any testcases that you add should go to testsuite/c-c++-common unless they are testing C-only or C++-only syntax. Cheers, Manuel.
