Re: windows build failure

[Eli Zaretskii]

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