> From: Bruno Haible <br...@clisp.org>
> Cc: bug-gnulib@gnu.org, psm...@gnu.org
> Date: Tue, 17 Sep 2019 00:45:03 +0200
>
> > > +@item
> > > +This function does not support the @code{X_OK} mode on some platforms:
> > > +MSVC 14.
> >
> > This says MSVC, but the code will do the same on MinGW, right?
>
> Yes, I enabled this code also on mingw. With the mingw version I tested,
> it is a no-op, because that mingw version links against an older MSVCRT
> runtime. If/when mingw starts to link against newer Microsoft ucrt runtimes,
> it will be affected by the same problem.
I'm saying that the documentation should mention MinGW as well,
because currently it gives an impression that only MSVC builds are
affected in any way.
> > > +int
> > > +access (const char *file, int mode)
> > > +{
> > > + if ((mode & X_OK) != 0)
> > > + mode = (mode & ~X_OK) | R_OK;
> > > + return _access (file, mode);
> >
> > This implementation is IMO less useful than it could be: it could also
> > look at the file-name extension and see if it's one of the known
> > executable extensions.
>
> Should it look whether the file name contains a '.'? (Recall that
> files without a '.' are not executable by execlp/execvp.) Yes, it could
> be done. But I don't see a compelling argument to do it, so far.
>
> Should it look whether the file extension is one of the known ones?
> Definitely not. When you rename a file prog.exe to prog.foo and invoke
> it through execlp/execvp, it works. And '.foo' is surely not one of the
> "known" file extensions.
You describe a very unusual situation, because prog.foo will not be
found by the Windows shell and by many other programs that use the
shell via the likes of 'system' and 'popen'. I think it's better to
be 90% correct than do nothing about this issue because we cannot
easily be 100% correct. Callers don't usually expect an X_OK test to
degenerate into F_OK, IMO.
IOW, I think this implementation doesn't live up to Gnulib's promise
to be a portability layer, because it loses too much of the baby with
the bath water.
