Mark Mitchell wrote:
> I'm disappointed to hear that MinGW made this change. As a MinGW user,
> I don't want MinGW to interpose anything between me and the MSVCRT
> libraries. I want MinGW to give me headers and import libraries for the
> Microsoft DLLs, with all their warts; nothing more, nothing less.
I may have overstated the nature of the change, as it still requires
#defining a symbol to get a change in behavior:
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char* __fname, int __mode)
{ return _access (__fname, __mode & ~X_OK); }
#define access(__f,__m) __mingw_access (__f, __m)
#endif
So the default behavior is still the broken wartyness of X_OK.
> Obviously, I don't have any say or control over MinGW; I'm just
> providing feedback as a long-term MinGW user. When I want a UNIX-like
> environment on Windows, I use Cygwin; when I want an alternative to
> VisualStudio for "native" Windows applications, I use MinGW. I'd prefer
> that code I write with MinGW also work with VisualStudio and vice versa.
There is a long precedent for MinGW implementing/augmenting the MSVCRT
interface in the form of libmingwex for C99 complex math for example.
> In my opinion, this is a GCC bug: there's no such thing as X_OK on
> Windows (it's not in the Microsoft headers, or documented by Microsoft
> as part of the API), and so GCC shouldn't be using it. The Vista
> runtime library chooses to issue an error when you set random bits in
> the mode provided to access, which is its privilege.
>
> There's a simple GCC change to fix this: have libiberty wrap the access
> function and mask out X_OK on non-Cygwin Windows. It's reasonable to
> put this change in libiberty, since it's job is to provide portability
> between systems.
This is also true, so I suppose it's not entirely correct to say that
this is not a gcc issue in the slightest. This above should indeed go
into libiberty as the long term solution. But no change today will
affect the MinGW system compiler (gcc 3.4.5 with a large amount of local
patches) which must be rebuilt one way or another, either by a patched
/mingw/include/io.h or by auditing all the source code and removing
X_OK, and the former is clearly less work than the latter. And the
__USE_MINGW_ACCESS feature can apply to porting other arbitrary packages
to Vista, without any source auditing.
Brian
