On Thu, Jul 6, 2017 at 8:51 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Thu, Jul 6, 2017 at 4:18 PM, Kuntal Ghosh <kuntalghosh.2...@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 <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers