This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MinGW, GCC Vista,

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:

/*  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)

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]