Re: libidn2 2.0.5 fails test-lookup on debian sid arch=ppc64

[Dennis Clarke]

On 06/28/2018 10:52 AM, Tim Rühsen wrote:
> Hi Dennis,
>
> there is something going on that I do not understand.

Cool.  Me neither.

> The code in libidn2 checks some combinations of input flags, the code is
> pretty simple. In two cases the check says OK instead of the expected
> error. I don't see any endianess issues there, but maybe I am blind.
>
> The following combinations of flags should give an error:
> IDN2_NONTRANSITIONAL|IDN2_TRANSITIONAL
> IDN2_NONTRANSITIONAL|IDN2_NO_TR46
> IDN2_TRANSITIONAL|IDN2_NO_TR46
> IDN2_TRANSITIONAL|IDN2_NONTRANSITIONAL|IDN2_NO_TR46

I have to agree that both systems are big endian.

> But your log shows #2 and #3 return OK (expected rc -209 got rc 0).

No idea what you are referring to but I'll assume that you know :-)

> The code is
> if (((*flags) & IDN2_TRANSITIONAL) && ((*flags) & IDN2_NONTRANSITIONAL))
>    return IDN2_INVALID_FLAGS;
>
> if (((*flags) & (IDN2_TRANSITIONAL|IDN2_NONTRANSITIONAL)) && ((*flags) &
> IDN2_NO_TR46))
>    return IDN2_INVALID_FLAGS;
>
> Where/how did you get the sources (git or tarball) ?

Directly from ftp.gnu.org/pub/gnu and on both systems the sha256 hash
 matches :

1) the Debian sid ppc64 machine

nix$ uname -a
Linux nix 4.17.2-genunix #1 SMP Fri Jun 22 23:42:51 GMT 2018 ppc64 GNU/Linux
nix$

nix$ /usr/local/bin/openssl dgst -sha256 ../src/libidn-1.35.tar.gz
SHA256(../src/libidn-1.35.tar.gz)= 
f11af1005b46b7b15d057d7f107315a1ad46935c7fcdf243c16e46ec14f0fe1e
nix$ /usr/local/bin/openssl dgst -sha256 ../src/libidn2-2.0.5.tar.gz
SHA256(../src/libidn2-2.0.5.tar.gz)= 
53f69170886f1fa6fa5b332439c7a77a7d22626a82ef17e2c1224858bb4ca2b8
nix$

2) ye old Solaris 10 Sparc machine

n0$ uname -a
SunOS node000 5.10 Generic_150400-61 sun4u sparc SUNW,SPARC-Enterprise
n0$

n0$
n0$ /usr/local/bin/openssl dgst -sha256 ../src/libidn-1.35.tar.gz
SHA256(../src/libidn-1.35.tar.gz)= 
f11af1005b46b7b15d057d7f107315a1ad46935c7fcdf243c16e46ec14f0fe1e
n0$
n0$ /usr/local/bin/openssl dgst -sha256 ../src/libidn2-2.0.5.tar.gz
SHA256(../src/libidn2-2.0.5.tar.gz)= 
53f69170886f1fa6fa5b332439c7a77a7d22626a82ef17e2c1224858bb4ca2b8
n0$

> Did you 'make clean' before 'make && make check' ?

Make clean from fresh tarballs?  Nope.  Hardly see the point.

However I can tell you that the issue may entirely be due to a previous 
version being installed in /usr/local/lib and here is why I think that: 
because all the tests pass AFTER the installation and not before.

PASS: test-punycode
PASS: test-lookup
PASS: test-register
PASS: test-strerror
PASS: test-tounicode
============================================================================
Testsuite summary for libidn2 2.0.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

PASS: libidn2_to_ascii_8z_fuzzer
PASS: libidn2_to_unicode_8z8z_fuzzer
============================================================================
Testsuite summary for libidn2 2.0.5
============================================================================
# TOTAL: 2
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================


Annoying to say the least.

Well this isn't the first time or the last that I will see this sort of
 thing. Happens all the time when I build apache from the svn repo.


I'll go check on the Solaris sparc box but I bet I see the same results.

As for "docker" and stuff like that.  Nope.  These are real machines on
real hardware. Accept no substitutes as they say.  Feel free to drop me
a public key and you can ssh in and see for your self if you like.
Personally I think there is no better way to really shake loose the
possible problems in code than to compile on different architectures,
both big endian and little endian and risc and cisc and with very
different compilers on Linux and UNIX. You would be amazed at the things
that get kicked loose by the Oracle Studio 12.6 compilers.  They are
brutally strict.

Dennis Clarke