Re: Missing PG_INT32_MIN in numutils.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Missing PG_INT32_MIN in numutils.c
Date
Msg-id CA+TgmoYTkqPRL0VURtHFwGKVoUVFR77CL16A8XM3Z3QFQC36Lw@mail.gmail.com
Whole thread Raw
In response to Re: Missing PG_INT32_MIN in numutils.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Missing PG_INT32_MIN in numutils.c
List pgsql-hackers
On Wed, Apr 13, 2016 at 9:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 13, 2016 at 3:49 AM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> While going through numutils.c I found the following thing:
>>> --- a/src/backend/utils/adt/numutils.c
>>> +++ b/src/backend/utils/adt/numutils.c
>>> @@ -136,7 +136,7 @@ pg_ltoa(int32 value, char *a)
>>> * Avoid problems with the most negative integer not being representable
>>> * as a positive integer.
>>> */
>>> -   if (value == (-2147483647 - 1))
>>> +   if (value == PG_INT32_MIN)
>>> {
>>> memcpy(a, "-2147483648", 12);
>>> return;
>>> Attached is a patch. The interesting part is that pg_lltoa is not
>>> missing the check on PG_INT64_MIN.
>
>> Committed.
>
> I am not very convinced that this is an improvement, because you took
> what had been two hard-wired constants and replaced them with a symbol
> and a hard-wired constant.This is more prone to break, not less so.
> If there were a way to stringify PG_INT32_MIN's value for use in the
> memcpy (which would then better be strcpy), then converting *both*
> constants would be an improvement --- but otherwise I think this was
> best left alone.

*shrug*

I think it's kind of six of one, half a dozen of the other, but if you
feel strongly about it, revert the patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Marcelo Zabani
Date:
Subject: Html parsing and inline elements
Next
From: Robert Haas
Date:
Subject: Re: SET ROLE and reserved roles