Re: NULL passed as an argument to memcmp() in parse_func.c

Glen Knowles <gknowles(at)ieee(dot)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 described in 7.1.4. On such a call, a
function that locates a character finds no occurrence, a
function that compares 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 domain of the function,
or a pointer outside the address space of the program, or a
null pointer) or a type (after promotion) 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