Re: overflow in snprintf() when printing INT64_MIN

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: overflow in snprintf() when printing INT64_MIN
Date: 2018-09-28 00:34:54
Message-ID: 20180928003454.ls2iy7jblakac2rx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-09-27 20:18:12 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I just noticed, while reviewing a patch that corrects overflow handing
> > in snprintf, that we don't correctly handle INT64_MIN in snprintf.c:
>
> Well, you still get the right answer, even if the "-value" is
> nominally undefined.

Right.

> > I suspect the best way to fix this, would be to instead do:
>
> > /* Handle +/- */
> > if (dosign && adjust_sign((value < 0), forcesign, &signvalue);
> > uvalue = -(uint64) value;
> > else
> > uvalue = (uint64) value;
>
> Hm, what does -x mean for an unsigned value? I'm not really
> convinced this is conceptually better.

6.2.5 (9): "... A computation involving unsigned operands can never
overflow, because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one greater
than the largest value that can be represented by the resulting type."

(unsigned)((int)-1) == 4294967295
-(unsigned)4294967295 == 1

I think that's well defined.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-09-28 00:44:59 Re: overflow in snprintf() when printing INT64_MIN
Previous Message Gilles Darold 2018-09-28 00:32:49 Re: Ora2Pg v19.1 has been released