| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manu <manuelreyesbravo(at)gmail(dot)com> |
| Cc: | Marko Grujic <marko(dot)grujic(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: query_int wrongly parses zero-padded input |
| Date: | 2026-10-18 01:44:56 |
| Message-ID: | 198983.1792287896@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Manu <manuelreyesbravo(at)gmail(dot)com> writes:
> And that octal reading is the harmful part, not something worth keeping. A
> leading-zero operand containing an 8 or 9 is truncated silently, not
> rejected: '08' and '09' both parse as 0, '-08' as 0 with the sign dropped,
> '018' as 1, and '02147483647' as 9020. That is worse, and quieter, than
> the '010' -> 8 in Marko's report.
Oh, that's an excellent point: if we did want to go the direction of
exposing strtol's full behavior, we'd need to make the code check
that strtol ate the whole input, which it does not today. I think
it's unnecessary to add such a check if we switch to base 10
(maybe I'm wrong?).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-10-18 02:10:29 | Re: query_int wrongly parses zero-padded input |
| Previous Message | Manu | 2026-10-18 01:16:05 | Re: query_int wrongly parses zero-padded input |