Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
I have temporarily pushed Helge's patch until this is solved upstream. On 2024-09-11 17:01, Bo YU wrote: Hi, Sorry for jumping into this topic. Is there anything I can do to push for updates to this package? Becasue the package blocked debci team to create riscv64/testing chroot on our riscv64 workers due to this FTBFS on mips64el lead to fail to migrate. On Mon, Aug 12, 2024 at 10:33:28AM +0200, Aurelien Jarno wrote: Hi, ... But for upstream, it just hides the real bug. On those architectures, the NaN encoding is indeed different, but the resulted encoded data should be the identical, as defined in the RFC. Therefore I believe the real fix is to convert NaNs (and probably also infinities) during the encoding process. My initial thoughts is to report this to upstream and then we can disable/skip NaNs related test on Debian side. But I am not sure if this is appropriate so let me make sure first here. BR, Bo
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hi On 2024-09-11 23:01, Bo YU wrote: > Hi, > > Sorry for jumping into this topic. > > Is there anything I can do to push for updates to this package? > > Becasue the package blocked debci team to create riscv64/testing chroot > on our riscv64 workers due to this FTBFS on mips64el lead to fail to > migrate. > > On Mon, Aug 12, 2024 at 10:33:28AM +0200, Aurelien Jarno wrote: > > Hi, > ... > > > > But for upstream, it just hides the real bug. On those architectures, > > the NaN encoding is indeed different, but the resulted encoded data > > should be the identical, as defined in the RFC. Therefore I believe the > > real fix is to convert NaNs (and probably also infinities) during the > > encoding process. > > My initial thoughts is to report this to upstream and then we can Sounds good. > disable/skip NaNs related test on Debian side. But I am not sure if this > is appropriate so let me make sure first here. Yep, either that or ignoring the testsuite result on mips64el and hppa. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hi, Sorry for jumping into this topic. Is there anything I can do to push for updates to this package? Becasue the package blocked debci team to create riscv64/testing chroot on our riscv64 workers due to this FTBFS on mips64el lead to fail to migrate. On Mon, Aug 12, 2024 at 10:33:28AM +0200, Aurelien Jarno wrote: Hi, ... But for upstream, it just hides the real bug. On those architectures, the NaN encoding is indeed different, but the resulted encoded data should be the identical, as defined in the RFC. Therefore I believe the real fix is to convert NaNs (and probably also infinities) during the encoding process. My initial thoughts is to report this to upstream and then we can disable/skip NaNs related test on Debian side. But I am not sure if this is appropriate so let me make sure first here. BR, Bo signature.asc Description: PGP signature
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hi, On 2024-05-03 22:26, Vincent Bernat wrote: > Hello Helge, > > Couldn't the patch be pushed upstream? And maybe there should be an else > branch with the encoding of the other NaN? > I am not sure the patch is upstreamable. It basically disables the test on mips and hppa, which is fine for Debian given it is not a regression compared to the previous version where the testsuite was fully disabled. But for upstream, it just hides the real bug. On those architectures, the NaN encoding is indeed different, but the resulted encoded data should be the identical, as defined in the RFC. Therefore I believe the real fix is to convert NaNs (and probably also infinities) during the encoding process. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hello Helge, Couldn't the patch be pushed upstream? And maybe there should be an else branch with the encoding of the other NaN? On 2024-04-27 17:35, Helge Deller wrote: Source: libcbor Version: 0.10.2-1.2 Tags: ftbfs X-Debbugs-Cc: del...@debian.org libcbor fails to build from source on the hppa and mips architectures. Reason is, that a testcases which checks the binary representation of NaN fails on those architectures, because they use a different binary encoding of the bytes. See the "encoding" section at https://en.wikipedia.org/wiki/NaN for details. Failure except: 20: [ RUN ] test_float 20: [ ERROR ] --- difference at offset 2 0xffbf 0xffc0 20: difference at offset 3 0x 0x00 20: difference at offset 4 0x 0x00 20: 3 bytes of 0x1739c and 0xfa001b57 differ 20: [ LINE ] --- ./test/float_ctrl_encoders_test.c:150: error: Failure! 20: [ FAILED ] test_float 20: [ RUN ] test_double 20: [ ERROR ] --- difference at offset 2 0xfff7 0xfff8 20: difference at offset 3 0x 0x00 20: difference at offset 4 0x 0x00 20: difference at offset 5 0x 0x00 20: difference at offset 6 0x 0x00 20: difference at offset 7 0x 0x00 20: difference at offset 8 0x 0x00 20: 7 bytes of 0x1739c and 0xfa001b63 differ 20: [ LINE ] --- ./test/float_ctrl_encoders_test.c:177: error: Failure! The attached patch avoids this test on hppa and thus building libcbor succeeds. I did not test the patch on mips yet. Helge
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Source: libcbor
Version: 0.10.2-1.2
Tags: ftbfs
X-Debbugs-Cc: del...@debian.org
libcbor fails to build from source on the hppa and mips architectures.
Reason is, that a testcases which checks the binary representation
of NaN fails on those architectures, because they use a different binary
encoding of the bytes.
See the "encoding" section at https://en.wikipedia.org/wiki/NaN for details.
Failure except:
20: [ RUN ] test_float
20: [ ERROR ] --- difference at offset 2 0xffbf 0xffc0
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: 3 bytes of 0x1739c and 0xfa001b57 differ
20: [ LINE ] --- ./test/float_ctrl_encoders_test.c:150: error: Failure!
20: [ FAILED ] test_float
20: [ RUN ] test_double
20: [ ERROR ] --- difference at offset 2 0xfff7 0xfff8
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: difference at offset 5 0x 0x00
20: difference at offset 6 0x 0x00
20: difference at offset 7 0x 0x00
20: difference at offset 8 0x 0x00
20: 7 bytes of 0x1739c and 0xfa001b63 differ
20: [ LINE ] --- ./test/float_ctrl_encoders_test.c:177: error: Failure!
The attached patch avoids this test on hppa and thus building libcbor succeeds.
I did not test the patch on mips yet.
Helge--- test/float_ctrl_encoders_test.c.org 2024-04-27 14:49:38.175261711 +
+++ test/float_ctrl_encoders_test.c 2024-04-27 14:59:12.825184338 +
@@ -9,6 +9,16 @@
#include "assertions.h"
#include "cbor.h"
+/* In NaNs generated by the PA-RISC and old MIPS processors, the
+ * signaling/quiet bit is zero if the NaN is quiet, and non-zero if the NaN is
+ * signaling. Thus the binary representation is different to other
+ * architectures. See encoding section at https://en.wikipedia.org/wiki/NaN */
+#if defined(__hppa__) || defined(__mips__)
+#define ARCH_WITH_STD_IEEE_754_NAN 0
+#else
+#define ARCH_WITH_STD_IEEE_754_NAN 1
+#endif
+
unsigned char buffer[512];
static void test_bools(void **_CBOR_UNUSED(_state)) {
@@ -147,13 +157,15 @@
5);
assert_size_equal(5, cbor_encode_single(NAN, buffer, 512));
- assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x00}),
+ if (ARCH_WITH_STD_IEEE_754_NAN)
+ assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x00}),
5);
#ifndef _WIN32
// TODO: https://github.com/PJK/libcbor/issues/271
assert_size_equal(5, cbor_encode_single(nanf("3"), buffer, 512));
- assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x03}),
+ if (ARCH_WITH_STD_IEEE_754_NAN)
+ assert_memory_equal(buffer, ((unsigned char[]){0xFA, 0x7F, 0xC0, 0x00, 0x03}),
5);
#endif
@@ -174,7 +186,8 @@
9);
assert_size_equal(9, cbor_encode_double(nan(""), buffer, 512));
- assert_memory_equal(
+ if (ARCH_WITH_STD_IEEE_754_NAN)
+assert_memory_equal(
buffer,
((unsigned char[]){0xFB, 0x7F, 0xF8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}),
9);
@@ -182,7 +195,8 @@
#ifndef _WIN32
// TODO: https://github.com/PJK/libcbor/issues/271
assert_size_equal(9, cbor_encode_double(nan("3"), buffer, 512));
- assert_memory_equal(
+ if (ARCH_WITH_STD_IEEE_754_NAN)
+assert_memory_equal(
buffer,
((unsigned char[]){0xFB, 0x7F, 0xF8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03}),
9);
