From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thiago Nunes <thiagotnunes@gmail.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17839: Heap-buffer overflow on float8_to_char with invalid
 template
In-reply-to: 
 <CANf6e1JxUFXpkH-ZV1u=bDL4vekZsqxeTcRtHVM-A8DZNxgqkw@mail.gmail.com>
References: <17839-aada50db24d7b0da@postgresql.org>
 <3011659.1678834145@sss.pgh.pa.us>
 <CANf6e1JxUFXpkH-ZV1u=bDL4vekZsqxeTcRtHVM-A8DZNxgqkw@mail.gmail.com>
Comments: In-reply-to Thiago Nunes <thiagotnunes@gmail.com>
	message dated "Wed, 15 Mar 2023 12:17:38 +1100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3076955.1678844746.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Mar 2023 21:45:46 -0400
Message-ID: <3076956.1678844746@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3076956.1678844746%40sss.pgh.pa.us>
Precedence: bulk

Thiago Nunes <thiagotnunes@gmail.com> writes:
> I think your solution deals with all the cases, but I would like to poin=
t
> out how I fixed it locally. I recalculated Num.zero_end after this line =
(
> https://github.com/postgres/postgres/blob/REL_15_2/src/backend/utils/adt=
/formatting.c#L6716
> ):

> ```
> Num.zero_end =3D Num.pre + Num.post;
> ```

Hmm ... that seems a bit ad-hoc, because as far as I understand this
code, zero_end is supposed to track where is the last '0' format
character.  That shouldn't change just because we decided that the
data value overflowed.

			regards, tom lane