On Thu, Jul 6, 2017 at 8:51 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Thu, Jul 6, 2017 at 4:18 PM, Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote:
>> But, I'm little concerned/doubt regarding the following part of the code.
>> +/*
>> + * Converts an int64 from network byte order to native format.
>> + */
>> +static int64
>> +pg_recvint64(int64 value)
>> +{
>> + union
>> + {
>> + int64 i64;
>> + uint32 i32[2];
>> + } swap;
>> + int64 result;
>> +
>> + swap.i64 = value;
>> +
>> + result = (uint32) ntohl(swap.i32[0]);
>> + result <<= 32;
>> + result |= (uint32) ntohl(swap.i32[1]);
>> +
>> + return result;
>> +}
>> Does this always work correctly irrespective of the endianess of the
>> underlying system?
>
> I think this will have problem, we may need to do like
>
> and reverse complete array if byte order is changed
This comes from the the implementation of 64b-large objects, which was
first broken on big-endian systems, until Tom fixed it with the
following commit, and this looks fine to me:
commit: 26fe56481c0f7baa705f0b3265b5a0676f894a94
author: Tom Lane <tgl@sss.pgh.pa.us>
date: Mon, 8 Oct 2012 18:24:32 -0400
Code review for 64-bit-large-object patch.
At some point it would really make sense to group all things under the
same banner (64-b LO, pg_basebackup, and now pg_rewind).
> or we can use something like "be64toh"
That's even less portable. For example macos would need a macro to map
to OSSwapBigToHostInt64 or OSSwapLittleToHostInt64 from OSByteOrder.h.
Brr.
--
Michael