On Thu, Nov 06, 2025 at 11:10:00PM +1300, Thomas Munro wrote:
> Observing that mess, I kinda wonder what would happen if we just used
> a big hammer to redefine off_t to be __int64 ourselves. On the face
> of it, it sounds like an inherently bad idea that could bite you when
> interacting with libraries whose headers use off_t. On the other
> hand, the world of open source libraries we care about might already
> be resistant to that chaos, if libraries are being built with and
> without -D_FIILE_OFFSET_BITS=64 willy-nilly, or they actually can't
> deal with large files at all in which case that's something we'd have
> to deal with whatever we do. I don't know, it's just a thought that
> occurred to me while contemplating how unpleasant it is to splatter
> pgoff_t all over our tree, and yet *still* have to tread very
> carefully with the boundaries of external libraries that might be
> using off_t, researching each case...
Not sure about that. It's always been something we have tackled with
the various pg_ and PG_ structures and definitions. Not sure that
this has to apply here since we already have one pgoff_t for the
purpose of portability for quite a few years already (d00a3472cfc4).
--
Michael
