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 Makefile.
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 wit
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.
Can
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 a
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 com
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 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
>
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 t
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?
N
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 byte
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 i
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) shoul
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,
since
13 matches
Mail list logo
