Re: [PATCH] Do not assume glibc glob internals

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Date: Mon, 25 Sep 2017 11:48:11 -0400
> 
> On Sun, 2017-09-24 at 15:43 -0700, Paul Eggert wrote:
> > Paul Smith wrote:
> > > I can't answer your question, but the previous version of this
> > > function didn't do anything special with a "foo/" path, so if it
> > > doesn't work here it didn't work there either...?
> > 
> > Now I *know* I should have kept my mouth shut. :-)
> > 
> > Sorry, I'm lost here, partly because I don't know what is meant by
> > "previous version". I guess you're working in a private repository
> > and that I can't see what version is the "latest". I trust your
> > instinct for MS-Windows code more than I trust mine, so if you think
> > the latest version is OK then that's good enough for me.
> 
> Well, that's sad on both our parts :).  I usually bumble along until
> Eli whacks me on the head and points out where my POSIX blinders have
> led me.

Not sure whether we are there already with this discussion. ;-)

Anyway, Paul Eggert is right, in that, if some code assumes that
"foo/" should have the semantics of 'foo' being a directory, then the
corresponding MS-Windows APIs emulating Posix functions will not
generally support that.  One example I know of is this:

  int foo_is_a_directory = access ("foo/", F_OK) == 0;

AFAIU, on Posix platforms the trailing slash makes sure that 'foo'
exists and is a directory, but on Windows the slash is removed before
the filesystem is queried, so the directory semantics is lost.  On
Windows, one needs to use D_OK (which is not universally supported),
or check for a directory separately.

That said, I'm not sure the above is relevant for the issue at hand.
Is it?  Are there other situations where Make uses "foo/" and expects
that to mean that 'foo' is a directory?  If so, what are those cases,
and could someone please point me to the relevant code in Make that I
should review?

Thanks.