Re: stat() on Windows might cause error if target file is larger than 4GB

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: stat() on Windows might cause error if target file is larger than 4GB
Date: 2018-09-13 14:29:44
Message-ID: 11523.1536848984@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Wed, Sep 12, 2018 at 08:17:05PM -0400, Tom Lane wrote:
>> And we can't just "#define stat __stat64" because
>> that would break the calls to stat(). Or wait, maybe we could do that
>> and also have a one-liner function named __stat64 that would catch the
>> calls and redirect to _stat64?

> I don't think I grab your point here. "#define stat __stat64" cannot
> exist from the start so how would you do that?

What I was vaguely imagining is that win32_port.h could #include
whichever Windows header defines these functions and structs, and
then do

#define stat __stat64

static inline ... __stat64(...) { return _stat64(...); }

What would need testing is whether the #define has nasty side-effects
even if we've already included the system header. I don't think it'd
hurt, eg, local variables named "stat"; though people might be surprised
when examining things in a debugger.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2018-09-13 15:33:39 Re: speeding up planning with partitions
Previous Message Tom Lane 2018-09-13 14:25:21 Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused