>> I put __nonnull__ declarations >> 1) in places where passing a NULL pointer leads to undefined behaviour, >> 2) in places where POSIX says that the function will always fail when a >> NULL >> pointer is passed. (For example: tsearch.) >> glibc uses __nonnull__ declarations only for case 1. But IMO warning also in >> case 2 will be more good than bad. > > Good! Thanks for doing all that work.
I found this: +extern int rpl_accept (int, struct sockaddr *, int *) _GL_ARG_NONNULL ((3)); do you plan on adding 2-argument versions of the macro, such as _GL_ARG_NONNULL2? >> Two points I'm not sure about: >> - Should the macro be called _GL_ARG_NONNULL or GL_ARG_NONNULL? >> - Is it worth putting the macro definition (always the same 10 lines of >> code) >> into a separate file, like done with link-warning.h? > > I lean towards _GL_ARG_NONNULL, for slightly less risk of impact > on application name space. With OpenGL identifiers starting with GL it's a tough call anyway, especially for preprocessor identifiers (for others OpenGL uses camel case). I'd go for GNULIB_ARG_NONNULL. Paolo
