Re: BUG #16953: OOB access while converting "interval" to char
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: t.larionov@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2021-04-09T10:42:46Z
Lists: pgsql-bugs
Attachments
- v2-fix_rm.diff (text/plain) patch v2
On Thu, Apr 08, 2021 at 08:37:21PM +0900, Michael Paquier wrote: > On Thu, Apr 08, 2021 at 07:04:03PM +0800, Julien Rouhaud wrote: > > I'm fine with it too, although I'd probably go with [-13, 13] just to make sure > > that there's isn't silly off-by-one mistake. > > Also, I guess that you'd just want to compile twice a modulo based on > MONTHS_PER_YEAR to get the correct positive position in each array. I'm not sure what you mean by that. We receive a pg_tm struct which can't contain more than 12 in tm_mon right? And actually for intervals it will reduce "12 months" to "1 year 0 month", so to_char previously didn't report anything for 12 months either. > > > I'll just wait a bit to see if anyone else has any opinion on whether -1 month > > should be January or December. > > Sure. If you can send an updated patch, that would be great. Hearing no other opinion I went with -1 -> december and so on in attached v2. I also fixed the "[-]12 months" case and updated the regression tests. Given the extra code needed to deduce the correct array position I factorized DCH_RM and DCH_rm.
Commits
-
Fix out-of-bound memory access for interval -> char conversion
- 6540322fad8b 9.6.22 landed
- 1cc110f68dcc 10.17 landed
- 5656f2c3dce5 11.12 landed
- 82dd5706ee5a 12.7 landed
- be79debd9688 13.3 landed
- 7a3972597f6e 14.0 landed