Signed-ness of ints is unclear in FE-BE protocol docs

On 2020-06-09 23:35, PG Doc comments form wrote:

The protocol docs generally do not mention whether ints are signed or
unsigned - this has actually bitten me once in the past, where a signed int
was accidentally used to interpret an unsigned int coming from PostgreSQL,
leading to issues. The ambiguity has made me resort to inspecting the
PostgreSQL sources in order to be sure.

First, I'd consider clarifying this on the "Message Data Types" page
(https://www.postgresql.org/docs/current/protocol-message-types.html).

sure

Second, across the protocol docs, rather than using Int32 and Int64, which
generally look like they're signed (depending on which language you're
coming from), I'd consider using UInt32/UInt64, which are unambiguous with
regards to signed-ness.

Well, they are actually signed, so I'm confused why you think we should
change the documentation to unsigned.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Second, across the protocol docs, rather than using Int32 and Int64,

which

generally look like they're signed (depending on which language you're
coming from), I'd consider using UInt32/UInt64, which are unambiguous

with

regards to signed-ness.

Well, they are actually signed, so I'm confused why you think we should
change the documentation to unsigned.

Interesting... I'm not 100% sure, but I recently received a report that the
WAL coordinates in XLogData (
https://www.postgresql.org/docs/current/protocol-replication.html) are
unsigned longs, is that a mistake? Are you saying all values in the
protocol are always signed?

On Thu, 11 Jun 2020 at 15:07, Shay Rojansky <roji@roji.org> wrote:

Second, across the protocol docs, rather than using Int32 and Int64,
which

generally look like they're signed (depending on which language you're
coming from), I'd consider using UInt32/UInt64, which are unambiguous

with

regards to signed-ness.

Well, they are actually signed, so I'm confused why you think we should
change the documentation to unsigned.

Interesting... I'm not 100% sure, but I recently received a report that
the WAL coordinates in XLogData (
https://www.postgresql.org/docs/current/protocol-replication.html) are
unsigned longs, is that a mistake? Are you saying all values in the
protocol are always signed?

AFAICS, the definition is correct. Int64 means an 64-bit integer in network
byte order [1]https://www.postgresql.org/docs/current/protocol-message-types.html. It does not mention signedness. All LSNs in the protocol
messages are advertised as Int64. A possible improvement is to inform that
that Int64 is a XLogRecPtr in each message block that contains LSN. It used
to be like that before the commit add6c3179a4d4fa3e62dd3e86a00f23303336bac

-          The starting point of the WAL data in this message, given in
-          XLogRecPtr format.
+          The starting point of the WAL data in this message.

but it was removed for an unknown reason.

[1]: https://www.postgresql.org/docs/current/protocol-message-types.html

--
Euler Taveira http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services