Hi,
On 2019-04-29 10:16:39 -0700, Peter Geoghegan wrote:
> On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <andres@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