[PATCH 2/2] Windows libcpp: Make path-exists semantics more Posix-like

[Kai Tietz]

2014-04-25 21:24 GMT+02:00 Pedro Alves <palves@redhat.com>:
> On 04/25/2014 08:05 PM, Kai Tietz wrote:
>> 2014-04-25 18:53 GMT+02:00 Pedro Alves <palves@redhat.com>:
>>> On 04/19/2014 09:41 PM, Kai Tietz wrote:
>>>
>>>> Isn't this function something better placed in libiberty?  Also this name looks a bit confusing.  Wouldn't be a an function calling for _WIN32 case also stat, and just overrides the st_mode member, if it is a link better.  So I would put this function to the file_... API of libiberty.
>>>
>>> I'd even suspect that e.g., GNU Make / Makefiles would be likewise affected
>>> by this.  A solution for this in gcc, or in a few selected programs
>>> only, looks brittle to me.  Perhaps it should be mingw itself that provides
>>> a _non-default_ replacement as option (similarly to __mingw_printf).
>>
>> Of course we could change default-behavior of stat-function within
>> mingw.
>
> Huh?  I said exactly the opposite.  To expose it as a __non-default__
> replacement.  I pointed at __mingw_printf, so to suggest programs
> would call it like __mingw_stat or something, or by defining
> __USE_MINGW_POSIX_STAT or something, just like one can define
> __USE_MINGW_ANSI_STDIO before including stdio.h.  I'll understand
> if you wouldn't want to support that as an option, but I did _not_
> suggest making it the default.

As none-default replacement it makes even less sense in mingw IMO.
the __mingw_printf (and related functions) are there for providing C99
functionality.  What standard shall __mingw_stat satisfy?

>> I think that libiberty is exactly present to unify functionality (and
>> API) for different operation systems.  Exactly for this libiberty was
>> made, isn't it?
>
> libiberty is actually a kitchen sink, and specific to gcc and src.
Well it is shared with binutils.  And in the past gdb used it too (I
think it still does in some way, as not everything is in glib.  I
might be wrong about this).

> It does more than host abstraction.  Gnulib fills that role much better
> nowdays.  I'd be nice if gcc used that instead for the host abstraction
> parts (gdb does), but nobody's working on that afaik...

That's true for gdb.  I don't see that binutils or gcc use glib.  So I
can only talk in this thread about what gcc/binutils uses right now.
Actually I am not really interested in what kind of compatibility
library is used.
Nevertheless to hi-jack this thread to start a discussion about
preferring glib over other (already existing) library in gcc/binutils
isn't ok.  Please start for such a discussion a separate RFC-thread.

>> I agree that there are other venture, which might be affected by same
>> problem.  So those venture could either use libiberty to solve this
>> problem too, or need to reimplement it as they do now.
>
> And then we'll have reinvented Cygwin all over the map.  ;-)

Huh?  mingw != cygwin.  and mingw's internal libraries aren't a
kitchen-sink too.

>>> Can't glibc be changed to not rely on this?  /me hides.
>
> --
> Pedro Alves

---
Kai Tietz