Bug#576501: better example; and comments on resolution
In case the provided example seems too rare to expend much effort on, then
consider the common practice of returning NULL for a memory allocation request
of zero bytes.
As for the appropriate resolution of this bug:
The documentation of the nonnull attribute claims that
The compiler may also choose to make optimizations based on the knowledge
that certain function arguments will not be null.
Thus, for function arguments where NULL is indeed a permissible value,
it is indeed a bug to mark those arguments with the nonnull attribute
(at least in the presence of a compiler that does in fact make misoptimizations
as a result; I haven't checked whether any released version of gcc does, for
example).
(Whereas if the attribute's only effect were to issue warnings, then I would
instead recommend marking the bug as WONTFIX: it's permissible for warnings to
give false positives, and I suspect that the value of the true positives
outweighs the cost of the false positives, because I suspect it rare that the
compiler would falsely issue the warning.)
As for whether or not qsort, memcmp, memcpy, memmove etc. do in fact permit
NULLs: I see nothing in the documentation saying that the results are undefined for
NULLs, so presumably definedness is based only on whether any of the memory
accesses implied by the documentation are invalid; so I concur that NULL is
indeed a valid argument value when n==0.
Perhaps the aim of the nonnull attribute in these cases can be better achieved
with something along the lines of __builtin_object_size.
In addition, I would be inclined to file a bug against the gcc documenation,
given that it uses a memcpy-like function as an example of its use: I should
think that a warning about this issue would be appropriate.
pjrm.
Reply to: