| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Residual cleanups for tied objects in PL/Perl |
| Date: | 2026-08-17 18:08:28 |
| Message-ID: | 822136.1786990108@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Looking a bit more at the issue of standardizing our
perl-array-scanning code, I noticed that av_len returns SSize_t
not int, creating an overflow risk since we aren't consistent
about assigning the result to something wider than int. This
would only result in truncating the output not anything more
exciting, but it's still bad. Also, it seems from looking at
the Perl sources that they prefer to use av_count() to compute
the loop limit. That's the same as av_len()+1 (except it returns
Size_t), but I think that's a better habit to be in since it
removes the risk of forgetting to add 1. So here is a patch
that just cleans up those issues.
I'm inclined to push this, and separately push a patch to
clean up the inconsistent hash accessing logic, and then deal
with magic objects on top of that.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Make-plperl-s-handling-of-Perl-arrays-safer-and-m.patch | text/x-diff | 4.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2026-08-17 18:15:48 | Re: GIN VACUUM can corrupt internal posting tree pages |
| Previous Message | Tom Lane | 2026-08-17 17:58:04 | Re: Residual cleanups for tied objects in PL/Perl |