------- Comment #8 from pmoulder at mail dot csse dot monash dot edu dot au 2010-05-12 09:25 ------- OK, on careful reading, I agree re memcpy etc. (see below).
Consequently, I amend my suggested change to the documentation to: - Add a sentence about implicit `this' argument (copied & pasted from the format_arg entry). - Although largely taken care of by the above, I'd still be inclined to rename the attribute parameter from âarg-indexâ to âarg-numberâ; and similarly to rename âstring-indexâ to âstring-arg-numberâ elsewhere in the texinfo node (in format and format_arg items). - Reword âargument index listâ to âargument number listâ (in the nonnull item). - Despite retracting the âwrongly used in glibcâ grounds, I think the concerns raised on the page I linked to are sufficient to merit giving more emphasis to the "The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null" sentence: that it be put it in a paragraph by itself, and adding a warning that a consequence would be that any checks for NULL in the function may be optimized away. Coming back to memcpy etc.: As this is such an edge case, I'll give more detail for my (revised) reasoning (partly for the benefit of certain others that I intend to refer to this discussion): - C99 §7.21.2.1 [#2]: âThe memcpy function copies n [i.e. 0] characters from the object pointed to by s2 into the object pointed to by s1.â Text is similar for memcmp, memmove, memset, and their w- (wmemcmp etc.) counterparts, in each case referring to âthe object pointed to by s/s1/s2â; while text for qsort says âsorts an array of nmemb objects, the initial element of which is pointed to by baseâ. - C99 §6.3.2.3 [#3]: âSuch a pointer [as NULL], called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.â Thus, if s/s1/s2 is a null pointer, then âthe object pointed to by s/s1/s2â isn't defined, so the sentence doesn't apply (despite copying/comparing only 0 bytes/characters from or to this undefined thing); and in each case there's no other text giving the behaviour when s/s1/s2 is a null pointer; so I conclude that the behaviour of these functions is indeed undefined when s/s1/s2 is a null pointer, so the âundefined behaviourâ provisions of §3.18 apply, and optimizing out the test for NULL is conformant behaviour as an instance of âignoring the situation [of s/s1/s2 == NULL] completely with unpredictable resultsâ (§3.18 [#2]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081