[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] non-null declarations

From: Ben Pfaff
Subject: Re: [PATCH] non-null declarations
Date: Thu, 10 Dec 2009 09:22:59 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Eric Blake <address@hidden> 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 __c is 0, it is safe for __s to be NULL.  On 
> the other hand, glibc already warns here, the gnulib testsuite already jumps 
> through hoops to avoid the warning, and the likelihood of meaning to pass 
> when __c is 0 is slim.  Your call.

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:

     Where an argument declared as size_t n specifies the length
     of the array for a function, n can have the value zero on a
     call to that function. Unless explicitly stated otherwise in
     the description of a particular function in this subclause,
     pointer arguments on such a call shall still have valid
     values, as described in 7.1.4.

Then, 7.1.4 "Use of library functions" explicitly calls out a
null pointer as an invalid value:

     If an argument to a function has an invalid value (such as a
     value outside the domain of the function, or a pointer
     outside the address space of the program, or a null pointer,
     or a pointer to non-modifiable storage when the
     corresponding parameter is not const-qualified) or a type
     (after promotion) not expected by a function with variable
     number of arguments, the behavior is undefined.
Ben Pfaff 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]