Re: [PATCH] non-null declarations

Hi Bruno, Bruno Haible writes: > > > Potential drawback of this approach is that these declarations may affect > > the implementation as well: there is a risk that compiler may optimize out > > NULL checks. In other projects where this issue arose before it was > > worked around by disabling non

Re: [PATCH] non-null declarations

Hi Dmitry, > Potential drawback of this approach is that these declarations may affect > the implementation as well: there is a risk that compiler may optimize out > NULL checks. In other projects where this issue arose before it was > worked around by disabling non-null declarations in implement

Re: [PATCH] non-null declarations

Hi, On Thu, Dec 10, 2009 at 03:36:18PM +0100, Bruno Haible wrote: > > Here's a proposed patch for introducing some __nonnull__ declarations. For > a start, I'm focusing on gnulib's replacement files lib/*.in.h, because these > declare the most often used functions. Potential drawback of this app

Re: [PATCH] non-null declarations

Eric Blake writes: > Ben Pfaff cs.stanford.edu> writes: >> ISO C99 requires that memchr's argument be nonnull even if __c is >> zero, as follows. 7.21.1 "String function conventions" says that >> pointer arguments must be valid even if the number of bytes is 0: > > But POSIX made the requiremen

Re: [PATCH] non-null declarations

Ben Pfaff cs.stanford.edu> writes: > >> extern void *memchr (void const *__s, int __c, size_t __n) > >> - __attribute__ ((__pure__)); > >> + __attribute__ ((__pure__)) _GL_ARG_NONNULL ((1)); > > > > This one I'm fuzzy on. On one hand, the POSIX definition is that the function > > reads a

Re: [PATCH] non-null declarations

On Thu, Dec 10, 2009 at 19:41, Bruno Haible wrote: > Paolo Bonzini wrote: >> accept4 has to be fixed to use ((2, 3)). :-) > > No, the second arg of accept4 can be NULL. See >   >  "When addr is NULL, nothing is filled in; in thi

Re: [PATCH] non-null declarations

Paolo Bonzini wrote: > accept4 has to be fixed to use ((2, 3)). :-) No, the second arg of accept4 can be NULL. See "When addr is NULL, nothing is filled in; in this case, addrlen is not used, and should also be NULL." I

Re: [PATCH] non-null declarations

Eric Blake wrote: > [about scandir] > > > Is there any desire to provide guaranteed extension semantics that cmp > > > can be > > > NULL in order to get an unsorted subset returned? > > > > I don't think this would be portable. You can in any case get an unsorted > > result by passing a cmp func

Re: [PATCH] non-null declarations

Bruno Haible clisp.org> writes: > > > extern int scandir (const char *dir, struct dirent ***namelist, > > > int (*filter) (const struct dirent *), > > > - int (*cmp) (const struct dirent **, const struct dirent **)); > > > + int (*cmp) (const struct dirent

Re: [PATCH] non-null declarations

Hi Eric, Thanks for the detailed review! Eric Blake wrote: > > - 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'd go one step further - I'd like to see it in config.h The reason for putting it

Re: [PATCH] non-null declarations

On Thu, Dec 10, 2009 at 18:12, Bruno Haible wrote: > Paolo Bonzini wrote: >> do you plan on adding 2-argument versions of the macro, such as >> _GL_ARG_NONNULL2? > > The macro already supports multiple parameter indices. Example: > > extern int scandir (const char *dir, struct dirent ***namelist,

Re: [PATCH] non-null declarations

Eric Blake writes: >> extern void *memchr (void const *__s, int __c, size_t __n) >> - __attribute__ ((__pure__)); >> + __attribute__ ((__pure__)) _GL_ARG_NONNULL ((1)); > > This one I'm fuzzy on. On one hand, the POSIX definition is that the > function > reads at most __c bytes, so when

Re: [PATCH] non-null declarations

Paolo Bonzini wrote: > do you plan on adding 2-argument versions of the macro, such as > _GL_ARG_NONNULL2? The macro already supports multiple parameter indices. Example: extern int scandir (const char *dir, struct dirent ***namelist, int (*filter) (const struct dirent *),

Re: [PATCH] non-null declarations

Bruno Haible clisp.org> writes: > Two points I'm not sure about: > - Should the macro be called _GL_ARG_NONNULL or GL_ARG_NONNULL? _GL_ARG_NONNULL is in the implementation-reserved namespace, so it is less likely to collide, but it is also more to type. I don't really care one way or anothe

Re: [PATCH] non-null declarations

>> 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 cas

Re: [PATCH] non-null declarations

Bruno Haible wrote: > Here's a proposed patch for introducing some __nonnull__ declarations. For > a start, I'm focusing on gnulib's replacement files lib/*.in.h, because these > declare the most often used functions. > > I put __nonnull__ declarations > 1) in places where passing a NULL pointer

Re: [PATCH] non-null declarations

Bruno Haible writes: > Opinions? Objections? Looks fine to me. I didn't test it, but obviously I'll report back if it breaks anything. /Simon