Noah Misch wrote:
You can write this more simply:
if (stat (path, &st) >= 0 && st.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH))
D'oh! You're right.
(Or even `access (path, X_OK) == 0', if MSYS has that.)
Err, well, sorta. What you're really asking is if "the C runtime
library(ies) exposed by the MinGW toolchain when running on MSYS and
building native win32 programs" has access().
That runtime is msvcrt.dll. And it does have access() -- but it has
always been broken with respect to X_OK. In previous versions of
Windows, msvcrt's access simply ignored the X_OK bit. However, as of
Windows Vista, it now returns an error if the X_OK bit is set.
New versions of the mingw headers do this:
#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
But that means, you have to #define __USE_MINGW_ACCESS, just to convince
"access()" (or the-function-you-get-when-you-try-to-call-access()) to
completely ignore X_OK like it used to do.
Ick. ltwrapper on mingw should stick with S_IXUSR | S_IXGRP | S_IXOTH
-- at least S_IXUSR works as expected.
The rest looks good to me. Thank you.
Thx.
--
Chuck
