Date: Fri, 29 Nov 2019 21:38:32 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: paul@intekon.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16143: PGTYPEStimestamp_fmt_asc() returns the incorrect
 month when the format specifier %b is used.
Message-ID: <20191129203832.xybuswyoa455mwy2@development>
References: <16143-0d861eb8688d3fef@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xz7rkmjkptwaiibh"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <16143-0d861eb8688d3fef@postgresql.org>
Precedence: bulk


--xz7rkmjkptwaiibh
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Fri, Nov 29, 2019 at 07:40:37PM +0000, PG Bug reporting form wrote:
>The following bug has been logged on the website:
>
>Bug reference:      16143
>Logged by:          Paul Spencer
>Email address:      paul@intekon.com
>PostgreSQL version: 11.5
>Operating system:   Redhat and Debian
>Description:
>
>PGTYPEStimestamp_fmt_asc() returns the incorrect month when the format
>specifier %b is used.  The returned month is one greater then the expected
>month.  If the expected month is “Dec”, the application may crash with a
>segment fault.  The format specifier %B has a similar issue.
>
>** Investigation Notes
>- The month is increased by one at line 143 in timestamp2tm() defined in
>timestamp.c  https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/ecpg/pgtypeslib/timestamp.c;h=810dd06ee68b9e39bfbb8d1fb4b58b8205f24246;hb=HEAD
>- The month number is converted to the abbreviation at line 337 in
>dttofmtasc_replace() defined in timestamp.c   https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/ecpg/pgtypeslib/timestamp.c;h=810dd06ee68b9e39bfbb8d1fb4b58b8205f24246;hb=HEAD
>- Month abbreviations are defined at line 499 in dt_common.c  
>https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/ecpg/pgtypeslib/dt_common.c;h=c1a3a3e2cb7e2d4f375a3b1a2e858f7347a867ea;hb=HEAD
>

Yeah, seems like a simple off-by-one mistake. Our tm->tm_mon is 1-based,
but dttofmtasc_replace uses it directly to access elements of arrays
with month names. Hence the "next" month is returned, and crash for the
last month (access out of bounds).

The attached patch should fix this, I believe - both for %b and %B.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 

--xz7rkmjkptwaiibh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ecpg-month-index-fix.patch"

diff --git a/src/interfaces/ecpg/pgtypeslib/timestamp.c b/src/interfaces/ecpg/pgtypeslib/timestamp.c
index 810dd06ee6..ddb82a1ad6 100644
--- a/src/interfaces/ecpg/pgtypeslib/timestamp.c
+++ b/src/interfaces/ecpg/pgtypeslib/timestamp.c
@@ -334,13 +334,13 @@ dttofmtasc_replace(timestamp * ts, date dDate, int dow, struct tm *tm,
 					/* XXX should be locale aware */
 				case 'b':
 				case 'h':
-					replace_val.str_val = months[tm->tm_mon];
+					replace_val.str_val = months[tm->tm_mon - 1];
 					replace_type = PGTYPES_TYPE_STRING_CONSTANT;
 					break;
 					/* the full name of the month */
 					/* XXX should be locale aware */
 				case 'B':
-					replace_val.str_val = pgtypes_date_months[tm->tm_mon];
+					replace_val.str_val = pgtypes_date_months[tm->tm_mon - 1];
 					replace_type = PGTYPES_TYPE_STRING_CONSTANT;
 					break;
 

--xz7rkmjkptwaiibh--