Andres Freund writes:
> On 2015-07-01 10:51:49 -0400, Tom Lane wrote:
>> 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
On 2015-07-01 10:51:49 -0400, Tom Lane wrote:
> 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 t
Piotr Stefaniak 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
Glen Knowles 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
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. I didn't see a good reference for C89
but I find it almost impos
Robert Haas writes:
> On Mon, Jun 22, 2015 at 2:55 PM, Tom Lane wrote:
>> If I recall that code correctly, the assumption was that if the third
>> argument is zero then memcmp() must not fetch any bytes (not should not,
>> but MUST not) and therefore it doesn't matter if we pass a NULL. Are
>> y
On Mon, Jun 22, 2015 at 2:55 PM, Tom Lane wrote:
> Piotr Stefaniak writes:
>> There are two places in parse_func.c where memcmp() conditionally gets a
>> NULL as its first argument, which invokes undefined behavior. I guess
>> gcc -O2 will make some assumptions based on memcpy's __nonnull attribu
Piotr Stefaniak writes:
> On 06/22/2015 08:55 PM, Tom Lane wrote:
>> If I recall that code correctly, the assumption was that if the third
>> argument is zero then memcmp() must not fetch any bytes (not should not,
>> but MUST not) and therefore it doesn't matter if we pass a NULL.
> It's not abo
Piotr Stefaniak writes:
> There are two places in parse_func.c where memcmp() conditionally gets a
> NULL as its first argument, which invokes undefined behavior. I guess
> gcc -O2 will make some assumptions based on memcpy's __nonnull attribute.
If I recall that code correctly, the assumption
