From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 5 Dec 2018 11:48:07 +0300 From: Vladimir Davydov Subject: Re: [PATCH 04/11] sio: fix passing negative size_t to sio_add_to_iov Message-ID: <20181205084807.rypqkdf6wfpkumze@esperanza> References: <20181203135003.beibxo7vwnwiam2m@esperanza> <747f4d88-4913-d99d-ee7f-0b9ca994258a@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <747f4d88-4913-d99d-ee7f-0b9ca994258a@tarantool.org> To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org List-ID: On Wed, Dec 05, 2018 at 12:29:20AM +0300, Vladislav Shpilevoy wrote: > > > 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. But we do it all the time when adding a negative value to an unsigned variable. Nobody cares since it conforms to the C standard. > > > > > That being said, I don't think we need this patch. > > > > As you wish. Removed in v2. Thanks.