Re: Network Byte Order Coercion

From: Christoph Haller <ch(at)rodos(dot)fzk(dot)de>
To: Volkan YAZICI <volkan(dot)yazici(at)gmail(dot)com>
Cc: PostgreSQL Interfaces <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: Network Byte Order Coercion
Date: 2005-05-18 11:09:42
Message-ID: 428B2276.7C2FFF55@rodos.fzk.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-interfaces

Volkan YAZICI wrote:
>
> Hi,
>
> In libpq example program 3 (testlibpq3.c), an int4 field is converted
> to host byte order:
>
> {{{
> /* Get the field values (we ignore possibility they are null!) */
> iptr = PQgetvalue(res, i, i_fnum);
>
> /*
> * The binary representation of INT4 is in network byte order,
> * which we'd better coerce to the local byte order.
> */
> ival = ntohl(*((uint32_t *) iptr));
> }}}
>
> (As I saw while reading "An Essay on Endian Order" [1]) I'm not so
> familiar with byte orders, but what's the point of coercion in here?
> Should we do it in every integer field we retrieved? What's the
> [dis]advantages of this? I'd be so appreciated for any explanation.
>
> [1] http://www.cs.umass.edu/~verts/cs32/endian.html
>
> Regards.
>

As long as binary results are retrieved, PG delivers the data
always in network byte order (big endian), no matter what byte
order the processor is actually using.

On a machine using big endian, functions like ntohl do nothing.
On little endian systems, ntohl reverses the byte order, so
the result is correct.

So, if you want to write portable code, you'll have to consider
the byte order, otherwise the same code would produce different
results on different machines (PC, MAC).
In the end it's not at all a question of advantages versus
disadvantages, you'll just have to do it.
HTH

Regards, Christoph

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Sean Davis 2005-05-18 22:36:50 perl and large objects
Previous Message Volkan YAZICI 2005-05-16 10:12:37 Network Byte Order Coercion