Ross Ridge wrote: > Mark Mitchell writes: >> 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. > > Strictly speaking, access() (or _access()) isn't a documented part of > any Windows ABI. It's only documented as part of the C Runtime Library > for Visual C++, a different product. This is an important distinction, > while MinGW should support Windows APIs as documented by Microsoft, > it's not ment to be compatable with Visual C++. MinGW does use the same > runtime DLL as used by Visual C++ 6.0, but this is essentially just an > implementation detail, not ment as a compatibility goal. There are a > few of ways MinGW's runtime is incompatable with Visual C++ 6.0.
OK. Unfortunately, I guess that's not what I hoped MinGW is. :-) (Again, I'm not trying to be critical: I like MinGW, and it's not my place to say what it ought to be. I'm just giving feedback as a user.) To me, the fact that it uses the MSVCRT runtime library is very important, and the Visual C++ interoperability is important. In light of Brian's comment that: > I may have overstated the nature of the change, as it still requires > #defining a symbol to get a change in behavior: it may be that MinGW is more like what I hope: unless I define the special symbol, MinGW doesn't interpose anything between me and the runtime library -- except that it defines X_OK, which, as you say, may have been a mistake, but is certainly water under the bridge! As a user, I certainly have no objection to MinGW offering more than Visual Studio, in terms of things like libmingwex. But, I would like to perserve the ability to use MSVCRT in all its warty glory. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
