futimens: Work around a GNU/Hurd bug.

On GNU/Hurd I see the following: FAIL: test-fdutimensat == test-utimens.h:80: assertion 'func (BASE "file", ts) == -1' failed FAIL test-fdutimensat (exit status: 134) FAIL: test-futimens === test-futimens.h:106: asserti

Re: mountlist for native Windows

Bruno Haible writes: > The code looks good. Just please add comments > /* Documentation: > */ > before each use of a native Windows API. I would like that reviewing > this code be easy. It's unlike the POSIX API, for which such annotations > are not neede

Prefer the __gnu_hurd__ macro over __GNU__.

Bruno Haible writes: >Please keep this consistent. Either use __GNU__ here too, or switch to >using __gnu_hurd__ everywhere. (I would vote for the latter, since >__gnu_hurd__ is less easy to confuse with __GNUC__.) I used __gnu_hurd__ because I didn't know __GNU__ existed until know.

utimensat: Make sure exit status in configure check doesn't exceed 127.

Bruno Haible writes: > 2) In the configure-time test in m4/utimensat.m4, you added > result |= 128; >However, the exit code of a program is limited to the range 0..127. >How to merge some of the bits? So far, this test fails with exit code > - 2 on AIX, > - 64 on macOS, Net

Re: utimensat: Work around a GNU/Hurd bug.

Hi Collin, > The following test fails on GNU/Hurd: > > test-utimens.h:80: assertion 'func (BASE "file", ts) == -1' failed > FAIL test-utimensat (exit status: 134) > > This is because utimensat does not validate the tv_nsec fields of it's > arguments. > > I have reported this bug to the

Re: mountlist for native Windows

Hi Collin, > > The questions is: which ones are useful in this context? > > I've attached a basic patch, but I have not pushed it since I am unsure > how useful it actually is or if I am missing important information. The code looks good. Just please add comments /* Documentation: