Glen Knowles <gknowles@ieee.org> writes:
> It appears that, according to the standard, passing NULL to memcmp is
> undefined behavior, even if the count is 0. See
> http://stackoverflow.com/questions/16362925/can-i-pass-a-null-pointer-to-memcmp
> for C99 and C++ standard references.
Hmm ... looks like that's correct. I had not noticed the introductory
paragraphs. For those following along at home, the relevant text in
C99 is in "7.21.1 String function conventions":
[#2] 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
describedin 7.1.4. On such a call, a function that locates a character finds no occurrence, a function
thatcompares two character sequences returns zero, and a function that copies characters copies zero
characters.
and the relevant text from 7.1.4 is
[#1] Each of the following statements applies unless explicitly stated otherwise in the detailed
descriptions| that follow: If an argument to a function has an invalid value (such as a value outside the
domainof the function, or a pointer outside the address space of the program, or a null pointer) or a type
(afterpromotion) not expected by a function with variable number of arguments, the behavior is undefined.
So it looks like we'd better change it.
I am not sure whether to put in the nargs == 0 test suggested yesterday
or to just insist that callers not pass NULL. A quick grep suggests that
there is only one such caller right now, namely this bit in ruleutils.c:
appendStringInfo(&buf, "EXECUTE PROCEDURE %s(", generate_function_name(trigrec->tgfoid, 0,
NIL, NULL, false, NULL, EXPR_KIND_NONE));
You could certainly argue that that's taking an unwarranted shortcut.
regards, tom lane
