Paul Eggert wrote:
> So possibly this behavior is also kernel-dependent
> (AT_EMPTY_PATH was introduced in Linux 2.6.39, maybe the kernels are
> buggy before that?).
That's well possible. I haven't investigated whether the unexpected
behaviour comes from glibc vs. from the kernel.
Bruno
+This function does not fail when the second argument is an empty string
+on some platforms:
+glibc 2.7.
If AT_EMPTY_PATH is specified, fstatat is documented to behave that way
with an empty string. So possibly this behavior is also kernel-dependent
(AT_EMPTY_PATH was introduced in Linux 2.
Paul Eggert wrote:
> On 5/9/21 7:51 AM, Bruno Haible wrote:
> > if (fd < 0)
> > -return fd;
> > +{
> > + errno = ENOSYS;
> > + return -1;
> > +}
>
> If 'open' fails with errno equal to (say) EINTR or EAGAIN or EMFILE,
> this doesn't mean the opera
On a glibc 2.7 system, a recent m4 tarball fails its tests, due to this:
FAIL: test-fstatat
==
../../tests/test-stat.h:49: assertion 'func ("", &st1) == -1' failed
FAIL test-fstatat (exit status: 134)
So, apparently, fstatat(_, "", _) succeeds instead of failing. fstatat
is imple
Building a current m4 snapshot on Minix 3.3, there are compilation errors,
such as:
---
In file included from ../../lib/execute.c:72:
./spawn.h:727:19: error: conflicting types for 'posix_spawn'
_GL_FUNCDECL_SYS (posix_spawn, int,
On NetBSD 8 and 9, in 64-bit mode, I see a test failure:
test-reallocarray fails with exit code 4.
The cause is that when n*s overflows, reallocarray(p,n,s) fails with
errno = EOVERFLOW — unlike other implementations that fail with errno = ENOMEM.
But EOVERFLOW is just as reasonable (even more rea
