bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib/lib/lstat.c on DJGPP v2.04


From: Eli Zaretskii
Subject: Re: gnulib/lib/lstat.c on DJGPP v2.04
Date: Sat, 26 Feb 2011 00:33:45 +0200

> Date: Fri, 25 Feb 2011 13:41:41 -0800
> From: Paul Eggert <address@hidden>
> CC: Bug-gnulib <address@hidden>
> 
> On 02/23/2011 01:47 AM, Eli Zaretskii wrote in 
> <http://lists.gnu.org/archive/html/emacs-devel/2011-02/msg00995.html>:
> 
> > An example of what could go wrong with these replacements can be seen
> > in this excerpt from rpl_lstat:
> >
> >    +  /* This replacement file can blindly check against '/' rather than
> >    +     using the ISSLASH macro, because all platforms with '\\' either
> >    +     lack symlinks (mingw) or have working lstat (cygwin) and thus do
> >    +     not compile this file.  0 len should have already been filtered
> >    +     out above, with a failure return of ENOENT.  */
> >    +  len = strlen (file);
> >    +  if (file[len - 1] != '/' || S_ISDIR (sbuf->st_mode))
> >    +    return 0;
> >
> > The assumption stated in the comment is wrong for DJGPP v2.04, which
> > is supported in the DOS build, where there's a working `symlink', but
> > a backslash is a valid directory separator.
> 
> I assume that you meant "lstat" when you wrote "symlink".

I meant both.

> Come to think of it, I don't see a problem here, even if this code
> were executed under DOS in the proposed Emacs patch (which it's not).
> The code in question is exercised only on hosts where lstat exists but
> mishandles file names with trailing slashes, e.g., lstat ("FOO/", ...)
> incorrectly reports on FOO instead of on the directory that FOO points
> to.  This doesn't apply to DJGPP v2.04, surely, so there could be no
> bug on DJGPP v2.04.

That might be so now, but a month or a year from now, someone will
decide that gnulib's `lstat' needs to fix some other anomaly, which
will cause DJGPP builds of some package out there to use this code.

My suggestion is simply to use ISSLASH everywhere.  This kind of
assumptions is a subtle bug waiting to happen.  There's no real
savings in comparing against a literal slash.  Instead of a lengthy
argument why not using ISSLASH it's easier to just use it.

> I'll CC: this to bug-gnulib in case someone there is interested in
> this sort of thing.

I hope they will be.



reply via email to

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