On 2024-12-09 we discussed:
> > It appears that this environment variable can cause trouble in some
> > situations. Therefore I would be in favour of adding a small paragraph
> > about it in the 'gnupload --help' output, but *not* set it inside the
> > script.
>
> OK, done via the attached.
In fa
On 2025-01-12 Paul Eggert wrote:
> On 2025-01-12 12:26, Lasse Collin wrote:
> > The patch makes readdir() detect that lossless conversion isn't
> > possible and inform the application with EOVERFLOW
>
> Wouldn't EILSEQ be more appropriate? That's what "open" is supposed
> to do with names that t
Lasse Collin wrote:
> The patch makes readdir() detect that lossless conversion isn't
> possible and inform the application with EOVERFLOW
Yes, that's my understanding as well.
> instead of returning a made-up name that might even be dangerous.
This "might be dangerous" claim is IMO exaggerated,
Collin Funk wrote:
> The only change to sys/wait.h in POSIX 2024 is that WCOREDUMP is now
> standardized. I've pushed the two attached patches updating a source
> comment and adding a test for the definition that was missing.
The CI reports a compilation error on all glibc systems.
How to reprod
Bruno Haible writes:
> The CI reports a compilation error on all glibc systems.
Thanks for the fix and glibc bug report.
I forgot that stdlib.h is supposed to define these macros as well.
Collin
This is mostly to document the bug.
If these old platforms were still common I suppose we should
change the readdir module to work around it. However, I’m not
sure it’s worth the hassle at this point.
* doc/posix-functions/readdir.texi, doc/posix-functions/readdir_r.texi:
Document the bug.
* lib/f
Pádraig Brady wrote:
> > Can you describe the circumstances where you observed the discrepancy?
>
> It impacts the tests when we `./configure --enable-single-binary=shebangs`.
Oh, I see. In this case, 'cp' for example is an executable script
#!/bin/coreutils --coreutils-prog-shebang=cp
This c
The git-version-gen thread reminded me that having include'able snippets
of these statements is increasingly useful... I get tired of manually
syncing the Makefile.am snippets from gnulib manual on every update in
gnulib.
What do you think of a etc/make/git-version-gen.mk include snippet?
There
Hi Collin,
> I noticed that test-strerrorname_np.c fails on the following line on
> GNU/Hurd:
>
> /* GNU/Hurd */
> #if defined ED_ALREADY_OPEN
> ASSERT (strcmp (strerrorname_np (ED_ALREADY_OPEN), "ED_ALREADY_OPEN") ==
> 0);
> #endif
>
> This is because glibc doesn't have GNU/Hur
Bruno Haible via Gnulib discussion list writes:
> Basil L. Contovounesios wrote:
>> Should 'make dist' also fail when $(srcdir)/.git does not exist
>
> Definitely not. It would prevent "make dist" from succeeding when
> run from an unpacked tarball.
Agreed. Thanks for these fixes! I pushed the
A gnulib testdir on Hurd/x86_64 [1] shows the same test failures as on
Hurd/i386, minus a 'FAIL: test-year2038', namely:
FAIL: test-fdutimensat
FAIL: test-futimens
FAIL: test-linkat
FAIL: test-renameat
FAIL: test-renameatu
FAIL: test-strerrorname_np
FAIL: test-utimensat
Find attached the test-sui
Hi Bruno,
I noticed that test-strerrorname_np.c fails on the following line on
GNU/Hurd:
/* GNU/Hurd */
#if defined ED_ALREADY_OPEN
ASSERT (strcmp (strerrorname_np (ED_ALREADY_OPEN), "ED_ALREADY_OPEN") == 0);
#endif
This is because glibc doesn't have GNU/Hurd errors in
sysdeps/gn
On 2025-01-13 Lasse Collin wrote:
> On 2025-01-12 Paul Eggert wrote:
> > Also, the POSIX spec suggests that readdir should return a null
> > pointer right away with errno set, rather than wait for the end of
> > the directory. A subsequent readdir resumes traversal of the
> > directory, even after
On 2025-01-13 Bruno Haible via Gnulib discussion list wrote:
> Without your patch, an application has the guarantee that when one of
> the file system APIs has returned a file name, the other file system
> APIs will be able to handle it (ignoring ENAMETOOLONG cases, which
> rarely occur in practice
On 2025-01-13 00:05, Lasse Collin wrote:
I pondered it before sending the patch. POSIX.1-2024 readdir() [1]:
[EOVERFLOW]
One of the values in the structure to be returned cannot be
represented correctly.
Yes, but the list of error numbers in the readdir ERRORS section i
15 matches
Mail list logo
