Re: [patch] fix nits in recent cwrapper patch

[Charles Wilson]

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