On Tue, Nov 18, 2025 at 9:18 PM Michael Paquier <[email protected]> wrote: > This is following the same pattern as what has been introduced in > 7dedfd22b798 for the other unsigned types in int.h. Anyway, looking > at that separately, the logic of 0001 seems right here.
Okay, good. Thanks for the review! > > 2) I have not implemented pg_neg_size_overflow(), because to me it > > seems likely to be permanently dead code, and it would require > > additional reasoning about the portability of SSIZE_MAX. > > (pg_sub_size_overflow(), by contrast, is easy to do and feels like it > > might be useful to someone eventually.) > > Documenting the portability issue is important, indeed. I'd suggest > to not use a ifdef 0, though, which may be confusing on grep if one > does not look at the surrounding lines. Leaving that in the shape of > a comment would be hard to miss. Done with a standard comment in v2, attached. Or were you also suggesting that I should just get rid of the sample, and rely on the comment above it? > Anyway, are you worrying about > SIZE_MAX matching with something different than the compile-time value > at runtime? (To avoid any confusion: I'm referring to SSIZE_MAX in particular, from POSIX, not SIZE_MAX which is C99.) My concern is that I'll need to add code to win32_port.h for this, alongside our existing ssize_t definition, and then use the buildfarm to flush out collisions with any other third-party headers that might have done the same on Windows. That seems like a lot of potential pain for no benefit. --Jacob
v2-0001-Add-pg_add_size_overflow-and-friends.patch
Description: Binary data
v2-0002-postgres-Use-pg_-add-mul-_size_overflow.patch
Description: Binary data
