Eric Blake <[email protected]> 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
> NULL
> 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
http://benpfaff.org
