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

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