Re: Regression test failures on big endian

Hi Christoph,

Sorry for the late reply.

On 2016/04/03 7:06, Christoph Berg wrote:
> Re: To PostgreSQL ODBC 2016-03-18 <20160318211558(dot)GA7269(at)msg(dot)df7cb(dot)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

The difference above is a natural outcome from the difference of endianness.

>> ***************
>> *** 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)

The difference above means that encoding of Unicode is UTF-16LE
whichever the endianness is.
Is it as you expected?

regards,
Hiroshi Inoue