On 12/11/21 03:35, Jan Nieuwenhuizen wrote:
It looks like the inode returned by
stat is always 0 on MinGW (at least it is under wine), so also when
choosing this approach we would need to special case our client code for
MinGW?
Yes, you'll have problems on such platforms. For ideas about this,
Hello Jan,
> > 2) If we wanted to make this function consistent on all platforms, we would
> >also need to handle
> > - Linux with mounted VFAT file systems,
> > - macOS with case-insensitive HFS+,
> > - different locales on Windows (e.g. to recognize that 'ä' and 'Ä' are
> >
Paul Eggert writes:
> On 12/9/21 22:59, Jan Nieuwenhuizen wrote:
>> We are using the canonical form as an automatic include guard, to not
>> include the same file twice.
>
> Gnulib's same-inode module is often a better way to attack that problem.
That's an interesting suggestion. It looks like t
On 12/9/21 22:59, Jan Nieuwenhuizen wrote:
We are using the canonical form as an automatic include guard, to not
include the same file twice.
Gnulib's same-inode module is often a better way to attack that problem.
n from adding code that requires GCC and does not work with
> MSVC.
Right, I will try to remember that. That's pretty terrible here, we
would need a global (or thread local storage) I guess.. Didn't fix this
in v2, as this isn't going in anyway.
Greetings,
Janneke
>From e5e7e10927d5c20
