Hi, On 2019-04-29 10:16:39 -0700, Peter Geoghegan wrote: > On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <and...@anarazel.de> wrote: > > I think we should start by just removing all uses of long. There's > > really no excuse for them today, and a lot of them are bugs waiting to > > happen. > > I like the idea of banning "long" altogether. It will probably be hard > to keep it out of third party code that we vendor-in, or even code > that interfaces with libraries in some way, but it should be removed > from everything else.
I don't think any of the code we've vendored in where we also track upstream, actually uses long in a meaningful amount. And putside of backward compatibility, I don't think there's many libraries that still use it. > > We read from larger files in a few places though. E.g. pg_dump. Most > > places really just should use pgoff_t... > > I wasn't even aware of pgoff_t. It is only used in frontend utilities > that I don't know that much about, whereas off_t is used all over the > backend code. Yea, we've some delightful hackery to make that work: * WIN32 does not provide 64-bit off_t, but does provide the functions operating * with 64-bit offsets. */ #define pgoff_t __int64 #ifdef _MSC_VER #define fseeko(stream, offset, origin) _fseeki64(stream, offset, origin) #define ftello(stream) _ftelli64(stream) #else #ifndef fseeko #define fseeko(stream, offset, origin) fseeko64(stream, offset, origin) #endif #ifndef ftello #define ftello(stream) ftello64(stream) #endif #endif which also shows that the compatibility hackery is fairly limited. Thomas, ISTM, that pg_pread() etc should rather take the offset as a uint64 or such. And then actually initialize OFFSET.offsetHigh. Greetings, Andres Freund
