Subject: Re: Int32 type unclear about signedness
To: rsto@paranoia.at, pgsql-docs@postgresql.org
References: <20170823184523.8152.35782@wrigleys.postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <bcd2c5e2-7ce0-ee5e-28ab-6a9981795c2d@2ndquadrant.com>
Date: Fri, 1 Sep 2017 22:12:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170823184523.8152.35782@wrigleys.postgresql.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

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


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs