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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
