Re: Regression test failures on big endian

Re: To PostgreSQL ODBC 2016-03-18 <20160318211558.GA7269@msg.df7cb.de>
> Hi,
>
> 09.05.0100 is failing the result-conversions tests on big endian
> architectures, e.g. powerpc:
>
> https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=powerpc&ver=1%3A09.05.0100-1&stamp=1458326445

Hi again,

these failures are preventing psqlodbc from entering the next Debian
release, and hence are critical.

Can anybody with more insight comment if the differences seen are real
problems or just cosmetic variations? In that case I could add more
_1.out files to catch them.

> * expected/result-conversions.out    Sun Jan 10 13:25:15 2016
> --- results/result-conversions.out    Fri Mar 18 18:40:34 2016
> ***************
> *** 262,270 ****
>   '1234567' (int4) as SQL_C_UTINYINT: 135
>   '1234567' (int4) as SQL_C_SBIGINT: 1234567
>   '1234567' (int4) as SQL_C_UBIGINT: 1234567
> ! '1234567' (int4) as SQL_C_BINARY: hex: 87D61200
>   '1234567' (int4) as SQL_C_BOOKMARK: 1234567
> ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 87D61200
>   '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0
>   '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000
>   '1234567' (int4) as SQL_C_GUID: SQLGetData failed
> --- 262,270 ----
>   '1234567' (int4) as SQL_C_UTINYINT: 135
>   '1234567' (int4) as SQL_C_SBIGINT: 1234567
>   '1234567' (int4) as SQL_C_UBIGINT: 1234567
> ! '1234567' (int4) as SQL_C_BINARY: hex: 0012D687
>   '1234567' (int4) as SQL_C_BOOKMARK: 1234567
> ! '1234567' (int4) as SQL_C_VARBOOKMARK: hex: 0012D687
>   '1234567' (int4) as SQL_C_TYPE_TIME: h: 0 m: 0 s: 0
>   '1234567' (int4) as SQL_C_NUMERIC: precision: 7 scale: 0 sign: 0 val: 87d61200000000000000000000000000
>   '1234567' (int4) as SQL_C_GUID: SQLGetData failed
> ***************
> *** 1328,1334 ****
>   'foobar' (text) as SQL_C_WCHAR: fooba (truncated)
>   'foobar' (text) as SQL_C_WCHAR: foobar
>   '' (text) as SQL_C_CHAR:
> ! '' (text) as SQL_C_WCHAR:
\FF00\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF
(truncated)
>   '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated)
>   '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated)
>   'NaN' (float4) as SQL_C_FLOAT: nan
> --- 1328,1334 ----
>   'foobar' (text) as SQL_C_WCHAR: fooba (truncated)
>   'foobar' (text) as SQL_C_WCHAR: foobar
>   '' (text) as SQL_C_CHAR:
> ! '' (text) as SQL_C_WCHAR: \
FF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF\FFFF
(truncated)
>   '2011-02-15 15:49:18' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:1 (truncated)
>   '2011-02-15 15:49:18 BC' (timestamp) as SQL_C_CHAR: 2011-02-15 15:49:18 (truncated)
>   'NaN' (float4) as SQL_C_FLOAT: nan
>
>
> The failure pattern is always the same:
> https://buildd.debian.org/status/package.php?p=psqlodbc
>
> (There is an extra problem with bulkoperations on sparc64, but that
> might be a problem with that port.
> https://buildd.debian.org/status/fetch.php?pkg=psqlodbc&arch=sparc64&ver=1%3A09.05.0100-1&stamp=1458326750
> )

Christoph