bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new module 'access'


From: Bruno Haible
Subject: Re: new module 'access'
Date: Tue, 17 Sep 2019 00:45:03 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-159-generic; KDE/5.18.0; x86_64; ; )

Hi Eli,

> > +@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.

> > +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.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]