From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 04/11] sio: fix passing negative size_t to sio_add_to_iov References: <20181203135003.beibxo7vwnwiam2m@esperanza> From: Vladislav Shpilevoy Message-ID: <747f4d88-4913-d99d-ee7f-0b9ca994258a@tarantool.org> Date: Wed, 5 Dec 2018 00:29:20 +0300 MIME-Version: 1.0 In-Reply-To: <20181203135003.beibxo7vwnwiam2m@esperanza> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: On 03/12/2018 16:50, Vladimir Davydov wrote: > On Fri, Nov 30, 2018 at 06:39:36PM +0300, Vladislav Shpilevoy wrote: >> sio_add_to_iov moves struct iov position on a >> specified offset, positive or negative. But its offset >> argument has size_t type, which is unsigned. Make it >> be ssize_t. >> >> This worked before thanks to how negative numbers are >> stored. For example, consider >> >> uint8_t value = 100; >> uint8_t offset = -5; >> >> Value is stored as 0110 0100. >> Offset is stored as 1111 1011. (Yes, 1011, not 1010). >> >> Sum of the values above is 0001 0101 1111 - first quad >> overflows and is truncated, so the result is >> 0101 1111 = 95 - correct. >> --- >> src/sio.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/sio.h b/src/sio.h >> index ab0a243cd..ff383aa36 100644 >> --- a/src/sio.h >> +++ b/src/sio.h >> @@ -84,7 +84,7 @@ sio_move_iov(struct iovec *iov, size_t nwr, size_t *iov_len) >> * to adjust to a partial write. >> */ >> static inline void >> -sio_add_to_iov(struct iovec *iov, size_t size) >> +sio_add_to_iov(struct iovec *iov, ssize_t size) >> { >> iov->iov_len += size; > > 'iov_len' has type size_t so 'size' will be converted to size_t before > the operation, in other words this patch has, in fact, no effect. It fixes corrupted logic - you should not accept negative numbers in positive types. Even if they are the same internally. > > Anyway, it's OK to apply unary minus to an unsigned variable: no matter > how integer types are stored, whether the machine uses two's-complement > or not, it should work so that (-x + x) equals 0. I do not argue with it. But then why do we have signed types? Lets use unsigned everywhere (). It does not matter does a compiler allow to turn a number into the complement or not. Logic of storing negative numbers in positive types is corrupted by definition. > > That being said, I don't think we need this patch. > As you wish. Removed in v2.