On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki <tomoa...@staff.kanazawa-u.ac.jp> wrote: > Hi, > > I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32) > gcc version 4.7.0 20111203 (experimental) (GCC) > > The code can be compiled with > > diff --git a/src/include/port.h b/src/include/port.h > index eceb4bf..78d5c92 100644 > --- a/src/include/port.h > +++ b/src/include/port.h > @@ -332,7 +332,7 @@ extern bool rmtree(const char *path, bool rmtopdir); > * Some frontends don't need the size from stat, so if UNSAFE_STAT_OK > * is defined we don't bother with this. > */ > -#if defined(WIN32) && !defined(__CYGWIN__) && !defined(UNSAFE_STAT_OK) > +#if defined(WIN32_ONLY_COMPILER) && !defined(UNSAFE_STAT_OK) > #include <sys/stat.h> > extern int pgwin32_safestat(const char *path, struct stat * buf); > > but, surely we need to know if it is ok or not > as the comment before says: > * stat() is not guaranteed to set the st_size field on win32, so we > * redefine it to our own implementation that is. > > Is there any simple test program that determines if the pgwin32_safestat > is required or the library stat is sufficient? > I presume the stat is a library function and therefore it depends on the > compiler rather than the WIN32 platform as a whole.
No, stat() is unreliable because it is implemented on top of FindNextFile(), and *that's* where the actual problem is at. And that's an OS API function, not a library function. See the discussion at http://archives.postgresql.org/pgsql-hackers/2008-03/msg01181.php In theory, if mingw implemented their stat() without using FindNextFile(), it might work - but I don't see how they'd do it in that case. And I can't see us going into details to remove such a simple workaround even if they do - it's better to ensure we work the same way with different compilers. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers