On 8/23/17 14:45, r...@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 -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
