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