From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17788: Incorrect memory access when parsing empty string as
 sql_standard interval
In-reply-to: <17788-dabac9f98f7eafd5@postgresql.org>
References: <17788-dabac9f98f7eafd5@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 12 Feb 2023 10:00:01 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <907584.1676224419.1@sss.pgh.pa.us>
Date: Sun, 12 Feb 2023 12:53:39 -0500
Message-ID: <907585.1676224419@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/907585.1676224419%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> When executing under valgrind:
> SET IntervalStyle TO sql_standard;
> SELECT ''::interval;

> The following error is detected:
> ==00:00:00:03.574 1155861== Use of uninitialised value of size 8
> ==00:00:00:03.574 1155861==    at 0x606ADE: DecodeInterval
> (datetime.c:3368)

Good catch!  For me, it dumps core about half the time even without
using valgrind.

> This defect was introduced by the commit e39f9904.
> Before that commit the check
> 	if (IntervalStyle == INTSTYLE_SQL_STANDARD && *field[0] == '-')
> was guarded by
> 	if (fmask == 0)
> 		return DTERR_BAD_FORMAT;
> but now field[0] is accessed unconditionally (even when nf == 0) for the
> SQL_STANDARD style.

Right.  Not checking nf > 0 wasn't great style there in any case,
but it accidentally failed to fail before.

Fix pushed --- thanks for the report!

			regards, tom lane