aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/transam/xlogreader.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2022-12-05 11:55:05 +1300
committerDavid Rowley <drowley@postgresql.org>2022-12-05 11:55:05 +1300
commit8692f6644e71f51db9a853a652f37909c9cb534d (patch)
tree387a99dda1704fee4a4ccc388cb827c96920aad6 /src/backend/access/transam/xlogreader.c
parentd94f32d49f620fb08c1fd0e8c9345844ccd9b7c0 (diff)
downloadpostgresql-8692f6644e71f51db9a853a652f37909c9cb534d.tar.gz
postgresql-8692f6644e71f51db9a853a652f37909c9cb534d.zip
Fix thinko introduced in 6b423ec67
As pointed out by Dean Rasheed, we really should be using tmp > -(PG_INTNN_MIN / 10) rather than tmp > (PG_INTNN_MAX / 10) for checking for overflows in the accumulation in the pg_strtointNN functions. This does happen to be the same number when dividing by 10, but there is a pending patch which adds other bases and this is not the same number if we were to divide by 2 rather than 10, for example. If the base 2 parsing was to follow this example then we could accidentally think a string containing the value of PG_INT32_MIN was an overflow in pg_strtoint32. Clearly that shouldn't overflow. This does not fix any actual live bugs, only some bad examples of overflow checks for future bases. Reported-by: Dean Rasheed Discussion: https://postgr.es/m/CAEZATCVEtwfhdm-K-etZYFB0=qsR0nT6qXta_W+GQx4RYph1dg@mail.gmail.com
Diffstat (limited to 'src/backend/access/transam/xlogreader.c')
0 files changed, 0 insertions, 0 deletions