Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 31, 2012 at 8:15 AM, Johann 'Myrkraverk' Oskarsson
> <johann@2ndquadrant.com> wrote:
>> 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.
I quote from the POSIX:2008 specification for <sys/stat.h>:
The following shall be declared as functions and may also bedefined as macros. Function prototypes shall be provided.
...int stat(const char *restrict, struct stat *restrict);
I do not believe that the standard intends the word "shall" to have any
wiggle room. I would also read this to mean that if the header defines
"stat" as a macro, that macro ought to be an alternative way of invoking
the function. Now we are messing up by failing to #undef the macro
before redefining it, but if we do that and it still doesn't work, the
header is not conformant to POSIX.
You can read this yourself at
http://pubs.opengroup.org/onlinepubs/9699919799/
> 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.
Well, I think it is. Where we use a wrapper function, it's because it
has somewhat different semantics from the underlying standard function.
I do not think it's good for readability to define pgfoo() when that's
only meant to be exactly foo(). I'm especially not keen on doing that
just because one variant of MinGW has managed to break their conformance
with POSIX.
regards, tom lane