Обсуждение: [DOCS] Int32 type unclear about signedness

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.6/static/protocol-message-types.html
Description:

The specification of the Int32 Message data type in section 51.4 of the
current documentation does to specify signedness (see [1]).

Both its C-like name and its use for negative values in several protocol 3
messages make assuming signedness only reasonable. Yet, when used for
message lengths, the libpq code seems unclear:

The libpq frontend reads message lengths from the backend as 4 bytes into a
signed int (see [2]). It checks if the length exceeds 30000 and allows
excessive message lengths only for some messages.

Yet, the related backend code uses a uint32_t to transmit the length value
of a size_t (see [3]). This suggests that UINT32_MAX lengths would
theoretically be possible and driver implementations would need to handle
it.

I'm almost certain that signed ints are meant, but it might not hurt to
explicitly state it in section 51.4. Furthermore, the restriction of certain
message lengths to 30000 is not documented.

Did I oversee something in the docs? Otherwise, I'd be happy to send a patch
with a suggested change in the documentation.

[1] https://www.postgresql.org/docs/9.6/static/protocol-message-types.html
[2]
https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-protocol3.c#L1985
[3]
https://github.com/postgres/postgres/blob/master/src/backend/libpq/pqcomm.c#L1570

P.S.: Thanks for PostgreSQL, such a great tool!

On 8/23/17 14:45, rsto@paranoia.at wrote:
> Both its C-like name and its use for negative values in several protocol 3
> messages make assuming signedness only reasonable. Yet, when used for
> message lengths, the libpq code seems unclear:
>
> The libpq frontend reads message lengths from the backend as 4 bytes into a
> signed int (see [2]). It checks if the length exceeds 30000 and allows
> excessive message lengths only for some messages.

That doesn't contradict anything about the value being signed.

> Yet, the related backend code uses a uint32_t to transmit the length value
> of a size_t (see [3]). This suggests that UINT32_MAX lengths would
> theoretically be possible and driver implementations would need to handle
> it.

That's because it calls ntonl() on the value, which requires an unsigned
argument.  It doesn't mean the original value is meant to be unsigned.

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