Re: Issues with MinGW W64
От | Robert Haas |
---|---|
Тема | Re: Issues with MinGW W64 |
Дата | |
Msg-id | CA+TgmobH7CT1f+=ZNQXm664OYDPHHU-5aySK6GJjBsJ3CdUDyw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Issues with MinGW W64 ("Johann 'Myrkraverk' Oskarsson" <johann@2ndquadrant.com>) |
Ответы |
Re: Issues with MinGW W64
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: