All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem Jan Withagen <wjw@digiware.nl>
To: Matt Benjamin <mbenjamin@redhat.com>
Cc: ceph-devel@vger.kernel.org
Subject: [patch] Re: compiling stops at od compare
Date: Sun, 31 Jan 2016 13:25:55 +0100	[thread overview]
Message-ID: <56ADFD53.4020401@digiware.nl> (raw)
In-Reply-To: <56AD4384.2030705@digiware.nl>

On 31-1-2016 00:13, Willem Jan Withagen wrote:
> On 30-1-2016 23:57, Matt Benjamin wrote:
>> Should we use std::min here (that might require a cast, iirc)?
> 
> Well the most important issue I have:
> 	while(len>0)
> where len is of type size_t has only exactly one chance to be true, aka
> len = 0. negative numbers do not exist.
> 
> So casting it to int is a bad(tm) thing.
> 
> But as I haven't designed the code, i can only react to the compiler
> error and analyze it. And then my conclusion is that the cast can only
> increase the chance on an error. And thus the compiler is correct in
> triggering.

Sorry,

I did not answer your question.

If using std::min requires a cast, then it will fall in the same pitfall
as the current code does. if there is a std::min version that does not
autocast/promote size_t to int it might work as well.
Using MIN does "the right thing", without the cast.

diff --git a/src/os/bluestore/BlueFS.cc b/src/os/bluestore/BlueFS.cc
index 1bad6a2..13555c9 100644
--- a/src/os/bluestore/BlueFS.cc
+++ b/src/os/bluestore/BlueFS.cc
@@ -728,7 +728,7 @@ int BlueFS::_read(
     left = buf->get_buf_remaining(off);
     dout(20) << __func__ << " left " << left << " len " << len << dendl;

-    int r = MIN((int)len, left);
+    int r = MIN(len, left);
     if (outbl) {
       bufferlist t;
       t.substr_of(buf->bl, off - buf->bl_off, r);

This does the job on Centos 7 for me....

--WjW

>> ----- 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
>>>
>>
> 
> --
> 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
> 

--
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

      reply	other threads:[~2016-01-31 12:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-30 13:22 compiling stops at od compare Willem Jan Withagen
2016-01-30 22:57 ` Matt Benjamin
2016-01-30 23:13   ` Willem Jan Withagen
2016-01-31 12:25     ` Willem Jan Withagen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56ADFD53.4020401@digiware.nl \
    --to=wjw@digiware.nl \
    --cc=ceph-devel@vger.kernel.org \
    --cc=mbenjamin@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.