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.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

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