On Thu, May 31, 2012 at 8:15 AM, Johann 'Myrkraverk' Oskarsson
<johann@2ndquadrant.com> wrote:
>>>> MinGW W64's sys/stat.h #defines stat to be _stati64 and there is
>>>> subsequently a compilation error in port.h:
>>>>
>>>> note: expected 'struct _stati64 *' but argument is of type 'struct
>>>> stat *' error: conflicting types for 'pgwin32_safestat'
>>
>>> In this case, I really think we ought to change all backend calls
>>> that hit stat() to use something like pgstat() instead.
>>
>> I disagree with this conclusion. That'd be an unnecessarily
>> nonstandard notation, which all existing and future developers would
>> have to learn. I'd rather work around this in port.h if at all
>> possible. I'm not quite sure why the existing code fails, though ---
>> is there a conflict between "#define stat" and "#define stat(a,b)"?
>
> I wouldn't know, the compiler is GCC 4.6.3 here (any 4.5+ will do I
> think) so all the usal GCC macro magic should be working.
>
> Is this something to discuss with the MinGW W64 team?
My viewpoint on this (which is different than Tom's) is that we're
probably not entitled to assume anything about what the system header
files do with respect to stat. On some systems, they might just have
a function prototype, while others might define stat or stat() as a
macro. It seems to me that our source code is hoping for a function
definition rather than a macro definition and falling over when that's
not how it is. I don't see that as very reasonable, unless we have
some basis for believing that the OS isn't entitled to define stat as
a macro rather than a function, and maybe not even then. We have
plenty of other places where we use our own wrapper function in lieu
of OS facilities for various reasons (e.g. BasicOpenFile) and I don't
think adding one more is a big deal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company