Re: Post-release followup: pg_add_size_overflow()

On Tue, Nov 18, 2025 at 9:18 PM Michael Paquier <michael(at)paquier(dot)xyz> 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