Re: endian: New module.

2024-05-18 Thread Collin Funk
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

Re: endian: New module.

2024-05-18 Thread Bruno Haible
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

Re: endian: New module.

2024-05-18 Thread Collin Funk
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.

Re: endian: New module.

2024-05-18 Thread Bruno Haible
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

Re: endian: New module.

2024-05-18 Thread Collin Funk
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

Re: endian: New module.

2024-05-18 Thread Bruno Haible
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

Re: endian: New module.

2024-05-18 Thread Bruno Haible
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

endian: New module.

2024-05-18 Thread Collin Funk
: [PATCH 1/2] endian: New module. * doc/glibc-headers/endian.texi, doc/gnulib-tool.texi: Mention it. * lib/endian.c: New file. * lib/endian.in.h: New file. * m4/endian_h.m4: New file. * modules/endian: New file. --- ChangeLog | 9 ++ doc/glibc-headers/endian.texi | 8 +- doc

Re: endian: New module.

2024-05-15 Thread Collin Funk
On 5/15/24 12:03 PM, Paul Eggert wrote: >> If we can ensure byteswap.h functions are defined as functions, >> wouldn't it make sense to just define these as macros to them? > > Not sure why macros would be helpful. If functions suffice for good > performance when compiling with -O2, it's better

Re: endian: New module.

2024-05-15 Thread Paul Eggert
On 2024-05-13 15:34, Collin Funk wrote: To fix this, please use _GL_INLINE and implement with inline functions. And add please add test cases to catch these issues. If we can ensure byteswap.h functions are defined as functions, wouldn't it make sense to just define these as macros to them?

Re: endian: New module.

2024-05-13 Thread Collin Funk
On 5/13/24 10:40 AM, Paul Eggert wrote: > Unfortunately this patch suffers from the problem we discussed earlier, e.g., > the substitute be16toh (n++) has undefined behavior but it should add 1 to n > and otherwise act as if be16toh (n) was called. [...] > These problems arise because Gnulib

Re: endian: New module.

2024-05-13 Thread Collin Funk
Hi Bruno, On 5/13/24 5:38 AM, Bruno Haible wrote: >> Let me know if I missed anything. Other than the docs and test module >> which I can do later today (assuming this patch is decent enough). > > The doc changes belong in the same commit. The tests module should be > in a different commit, but

Re: endian: New module.

2024-05-13 Thread Paul Eggert
Unfortunately this patch suffers from the problem we discussed earlier, e.g., the substitute be16toh (n++) has undefined behavior but it should add 1 to n and otherwise act as if be16toh (n) was called. Also, the returned values and types are sometimes wrong. E.g., on x86-64 be16toh (-1)

Re: endian: New module.

2024-05-13 Thread Bruno Haible
Hi Collin, > Let me know if I missed anything. Other than the docs and test module > which I can do later today (assuming this patch is decent enough). The doc changes belong in the same commit. The tests module should be in a different commit, but it's a good idea to develop both together,

endian: New module.

2024-05-13 Thread Collin Funk
enough). CollinFrom fe97691b765e57a9c5ea35dca5cb9502d284fb2b Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 13 May 2024 04:43:18 -0700 Subject: [PATCH] endian: New module. * modules/endian: New file. * lib/endian.in.h: New file, based on POSIX draft and glibc. * m4/endian_h.m4: New file, checks