[Bug middle-end/44081] Incorrect nonnull assumed in code generation

[pmoulder at mail dot csse dot monash dot edu dot au]

------- 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