Hi Bruno,
On 5/18/24 12:16 AM, Bruno Haible wrote:
>> I'll submit a bug report on the musl lists now.
>
> Thanks.
I submitted a report yesterday but forgot to link here [1].
>> I don't think this function is used too much
>
> Probably no one noticed the bug before, because the typical use of
Hi Paul,
Patch looks good.
On 5/18/24 7:04 PM, Paul Eggert wrote:
> Port to platforms lacking 64-bit integers (something that Emacs
> still attempts to do, in theory) by adding an u64bswap primitive
> to u64.h and using that, instead of using bswap_64. This fixes a
> bug I made in commit
Port to platforms lacking 64-bit integers (something that Emacs
still attempts to do, in theory) by adding an u64bswap primitive
to u64.h and using that, instead of using bswap_64. This fixes a
bug I made in commit 0d45ec7c033c165ad73a6509c7fa84aa67edf4ea
dated Sun Jun 17 14:35:37 2018 -0700.
*
Hi Bruno,
On 5/18/24 5:03 PM, Bruno Haible wrote:
>> Until then, maybe this should be added to the documentation? You
>> tested NetBSD 9.0 and NetBSD 10.0 and I reproduced on NetBSD 10.0.
>> From what I can tell from a brief look at the git history (don't know
>> how to use cvs, so github mirror)
Hi Collin,
> I've pushed the patch with a ChangeLog + the second of your
> suggestions.
Good!
> I've submitted a bug report with the links to documentation and a test
> program for them [1]. I think I even found the right place to change
> the behavior, so hopefully someone takes a look at it
Hi Bruno,
On 5/18/24 4:54 AM, Bruno Haible wrote:
>> +/* On NetBSD dup3 is a no-op when oldfd == newfd, but we expect
>> + an error with errno == EINVAL. */
>
> (What is "we", and who expects something from whom?)
> I would find it less confusing if written like this:
On 5/18/24 7:45 AM, Bruno Haible wrote:
>> Can you check the attached patch? I think that it should work or
>> at least be in the correct direction...
>
> In the endian.in.h file: The comments on the 3 last lines are not
> consistent with the '#endif' scopes.
Oops, good catch.
> In the
Sometimes a test has several failures on a certain platform (e.g. the
test-c32is* tests). In order to display all failed ASSERTs, not just the
first one, so far I hand-edited tests/macros.h.
But this approach does not work with CI builds, because
- it's not easy to hand-edit a file,
- it's
Paul Eggert wrote:
> > $ gcc -Wall -S foo.c
> > foo.c:1: warning: integer constant is too large for ‘long’ type
>
> I don't see how that would produce incorrect code for byteswap.h.
Indeed, gcc 4.4.7 warns but produces a long long value (no truncation).
> The longer story is C89 lacked 'long
On 2024-05-17 16:51, Bruno Haible wrote:
-- foo.c --
unsigned long long x = 0xff00;
---
$ gcc -Wall -S foo.c
foo.c:1: warning: integer constant is too large for ‘long’ type
I
Hi Collin,
> Can you check the attached patch? I think that it should work or
> at least be in the correct direction...
In the endian.in.h file: The comments on the 3 last lines are not
consistent with the '#endif' scopes.
In the Makefile.am snippet:
A few lines are indented with spaces, not
On 5/18/24 4:46 AM, Bruno Haible wrote:
>> I see. What is the correct solution here?
>
> See the idioms used by, say, arpa_inet.in.h.
>
>> Or something like this:
>>
>> #if @HAVE_ENDIAN_H@
>> # @INCLUDE_NEXT@ @NEXT_ENDIAN_H@
>> #endif
>
> This is part of it. But there's more details needed.
Hi Collin,
> How does this look? Passes tests on NetBSD 10.00.
The position in the code is right.
Only the comment is confusing me:
> +/* On NetBSD dup3 is a no-op when oldfd == newfd, but we expect
> + an error with errno == EINVAL. */
(What is "we", and who
Hi Collin,
> I sent a request for a compile farm account today since I realized I
> have no way of testing other architectures (other then VMs I guess).
That's reasonable. In particular, one cannot install macOS or AIX
in a VM, therefore for these two OSes the compilefarm is the only way
to get
Hi Bruno,
On 5/18/24 4:12 AM, Bruno Haible wrote:
> While testing a testdir for module 'endian' on gcc110.fsffrance.org
> (in the GCC compilefarm), I get a compilation error. This machine has
> a pretty old libc (glibc 2.17), but that ought to work anyway.
Oops, sorry.
I sent a request for a
Hi Collin,
While testing a testdir for module 'endian' on gcc110.fsffrance.org
(in the GCC compilefarm), I get a compilation error. This machine has
a pretty old libc (glibc 2.17), but that ought to work anyway.
gcc -std=gnu11 -DHAVE_CONFIG_H -I. -I../../gltests -I..
-DGNULIB_STRICT_CHECKING=1
Hi Bruno,
On 5/18/24 3:42 AM, Bruno Haible wrote:
> An interesting approach. But I think this added code comes too early:
> In case of oldfd == newfd && newfd < 0, it would fail with EINVAL instead
> of EBADF.
>
> How about trying the system call first, and test for newfd == oldfd only if
> that
Hi Collin,
> I've pushed the two patches adding a module to substitute endian.h.
> Pretty much the same as last time except using inline functions
> instead of macros and making sure variables are used in the m4 file.
Thanks!
> I've only mentioned the module in the documentation. It might make
Hi Collin,
> Currently dup3 is replaced unconditionally. I made this change in a
> NetBSD virtual machine and the test program passes:
>
> $ git diff .
> diff --git a/lib/dup3.c b/lib/dup3.c
> index a810d3be19..7674f042a4 100644
> --- a/lib/dup3.c
> +++ b/lib/dup3.c
> @@ -34,6 +34,15 @@ dup3
Hi Bruno,
On 5/17/24 2:10 PM, Bruno Haible wrote:
> On NetBSD 9.0 and 10.0, I always see the same tests fail:
>
> FAIL: test-dup3
> ===
>
> ../../gltests/test-dup3.c:113: assertion 'dup3 (fd, fd, o_flags) == -1' failed
> FAIL test-dup3 (exit status: 134)
It looks like dup3 behaves
I've pushed the two patches adding a module to substitute endian.h.
Pretty much the same as last time except using inline functions
instead of macros and making sure variables are used in the m4 file.
I've only mentioned the module in the documentation. It might make
sense to put it in
Hi Collin,
> I'll submit a bug report on the musl lists now.
Thanks.
> I don't think this function is used too much
Probably no one noticed the bug before, because the typical use of
this function is to test whether a given shell string is valid,
as in [1], and for this use, the bug hardly
22 matches
Mail list logo
