[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: windows build failure
From: |
Eli Zaretskii |
Subject: |
Re: windows build failure |
Date: |
Tue, 22 Feb 2011 03:57:35 -0500 |
> Date: Mon, 21 Feb 2011 18:09:07 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
>
> On 02/21/2011 12:37 PM, Eli Zaretskii wrote:
>
> > one fallout of the filemode.c import is that now all platforms
> > have S_IFLNK defined (by virtue of lib/sys_stat.h), so the remapping
> > of lstat to stat on fileio.c and dired.c is no longer needed, and can
> > be deleted. Unless I'm missing something, that is.
>
> Thanks for mentioning that. I committed simplifications along those
> lines to the trunk as revision 103380.
Thanks.
> One minor thing: Gnulib's <sys/stat.h> substitute guarantees
> the existence of S_ISLNK, but not S_IFLNK.
Yes, that was a typo on my part (to my defense, I would point out the
time when I wrote that ;-).
Please note that the portions of the code that need symlinks (and the
corresponding library functions) be supported by the host are
currently guarded by "#ifdef S_IFLNK", which the Windows and DOS
platforms do not define. OTOH, S_ISLNK _is_ defined on all
platforms. This makes me uneasy, because I've never seen a situation
with such a mismatch. Normally, if S_IFLNK is defined, so is S_ISLNK,
and vice versa. (I realize that this may have been otherwise in the
past, but I don't think any of those older systems are still in use,
or supported by Emacs.)
IOW, we use this mismatch as a trick to get filemode.c compile,
without breaking non-Posix platforms which don't really have symlinks.
I'm worried that someone unaware of this trick might assume that
S_IFLNK is also available, and will write code that will subtly break
non-Posix platforms.
If I'm not the only one who feels uneasy about this mismatch, we may
wish doing something about it.
(Personally, I wonder why gnulib removed the "#ifdef S_ISLNK" guards
in the first place: the artificial definition to zero in sys_stat.in.h
is only fine if one ignores the de-facto practice of testing for
S_IFLNK or S_ISLNK to guard code elsewhere that cannot be compiled or
run on platforms without symlinks. So it looks like an anti-social
decision on the part of gnulib, since it does support MinGW.)
- Re: windows build failure, (continued)
- windows build failure, Sean Sieger, 2011/02/21
- Re: windows build failure, Sean Sieger, 2011/02/21
- Re: windows build failure, Christoph, 2011/02/21
- Re: windows build failure, Paul Eggert, 2011/02/21
- Re: windows build failure, Eli Zaretskii, 2011/02/21
- Re: windows build failure, Paul Eggert, 2011/02/21
- Re: windows build failure,
Eli Zaretskii <=
- Re: windows build failure, Paul Eggert, 2011/02/22
- Re: windows build failure, Eli Zaretskii, 2011/02/22
- Re: windows build failure, Paul Eggert, 2011/02/22
- Re: windows build failure, Eli Zaretskii, 2011/02/23
- Re: windows build failure, Eli Zaretskii, 2011/02/23
- Re: windows build failure, Paul Eggert, 2011/02/25
- Re: Remove S_IFLNK (was: windows build failure), Eli Zaretskii, 2011/02/26
- Re: Remove S_IFLNK, Stefan Monnier, 2011/02/26
- Re: Remove S_IFLNK, Paul Eggert, 2011/02/26
- Re: Remove S_IFLNK, Eli Zaretskii, 2011/02/27