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

Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me> writes:
> On 06/27/2015 11:47 PM, Tom Lane wrote:
>> Given the utter lack of any evidence that this actually causes any
>> problems in the field, I don't feel a need to back-patch this change.

> I'm under the impression that you don't care about not avoiding
> undefined behavior as much as you care about "solving real problems"
> caused by it, whenever they show up in a report from one platform or
> another, or worse - when it's too late and somebody has reported an
> actual program misbehavior. The problem with that kind of thinking is
> that bugs caused by aggressive compiler optimizations taking advantage
> of invoking UB are a moving target (since compilers come and go, and the
> existing ones evolve) while the list of things not to do is constant and
> mostly clearly defined by the standard.

The problem is that there are multiple risks to manage here. If I were to
back-patch that patch, it would actively break any third-party extensions
that might be using the formerly-considered-valid technique of passing a
NULL array pointer to these lookup functions. We don't like breaking
things in minor releases; that discourages people from updating to new
minor releases.

As against that, we have exactly no reports of any field problems, and a
look at the two parse_func.c functions affected shows no reason to think
that there will ever be any; neither of them do anything much with their
argtypes argument except pass it to memcmp and other functions. So even
if the compiler did assume that argtypes couldn't be NULL, there would not
be much it could do with the assumption.

So my judgement is that the risks of back-patching this outweigh any
likely benefit. When and if some toolchain manages to actually break
things here, I could be proven wrong --- but I doubt that will happen
before 9.4 and earlier are out of support.

regards, tom lane