Re: pgsql: Further code review for pg_lsn data type.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Further code review for pg_lsn data type.
Date: 2014-02-20 14:59:51
Message-ID: 26907.1392908391@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> 6.3.1.3 Signed and unsigned integers, paragraph 3:
> "Otherwise, the new type is signed and the value cannot be represented
> in it; either the result is implementation-defined or an
> implementation-defined signal is raised."

"Implementation-defined" is entirely different from "undefined".
In practice, every two's-complement machine in the world is going
to define this behavior the same way. The standard is written the
way it is to avoid assuming that the underlying hardware is
two's-complement ... but there are no such machines outside museums.

I think you're making a problem out of nothing. We have considerably
more-real portability issues to worry about, like memory ordering.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2014-02-20 15:12:57 Re: pgsql: Further code review for pg_lsn data type.
Previous Message Andres Freund 2014-02-20 09:00:36 Re: pgsql: Further code review for pg_lsn data type.