Re: compiling stops at od compare

[Matt Benjamin <mbenjamin@redhat.com>]

Should we use std::min here (that might require a cast, iirc)?

Matt

----- Original Message -----
> From: "Willem Jan Withagen" <wjw@digiware.nl>
> To: ceph-devel@vger.kernel.org
> Sent: Saturday, January 30, 2016 8:22:07 AM
> Subject: compiling stops at od compare
> 
> When trying to compile on CentOS 7, gcc = 4.8.3
> 
> os/bluestore/BlueFS.cc: In member function ‘int
> BlueFS::_read(BlueFS::FileReader*, BlueFS::FileReaderBuffer*, uint64_t,
> size_t, ceph::bufferlist*, char*)’:
> os/bluestore/BlueFS.cc:731:31: warning: comparison between signed and
> unsigned integer expressions [-Wsign-compare]
>      int r = MIN((int)len, left);
> 
> This MIN is used to determine the amount of buffer that is still left
> to be filed.
> And here len and left are both size_t..., suggesting that both cannot be
> negative. So either both need to be promoted/cast, or neither.
> 
> The cast (int)len suggests that len could be negative.
> The part where that could happen is at line 750:
> 
>    off += r;
>     len -= r;
>     ret += r;
> 
> So there the loop exit needs len to be exactly equal to r. Even if the
> loop specifies while(len>0). if len gets "negative" it grows into
> something rather big.
> 
> Now if len never gets negative then it also does not need to get cast to
> int. If it does, then in the unsigned case it will always be larger than
> left.
> 
> So bottomline is that the cast serves no purpose?
> Removing it fixes compilation.
> 
> --WjW
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html