All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH blktests] Fix build failure for discontiguous-io on 32-bit platforms
Date: Mon, 29 Oct 2018 14:32:34 -0700	[thread overview]
Message-ID: <1540848754.196084.105.camel@acm.org> (raw)
In-Reply-To: <20181029210822.GA15839@thunk.org>

On Mon, 2018-10-29 at 17:08 -0400, Theodore Y. Ts'o wrote:
> On Mon, Oct 29, 2018 at 09:26:43AM -0700, Bart Van Assche wrote:
> > 
> > Have you considered to change the data type of 'len' from size_t into unsigned long
> > instead of inserting this cast? That would make it clear that no integer truncation
> > happens in the iov.append() call.
> 
> Well the potential integer truncation that could happen is here:
> 
>                 case 'l': len = strtoul(optarg, NULL, 0); break;

If the data type of 'len' would be changed into unsigned long, how could that
assignment cause integer truncation since strtoul() returns an unsigned long
value? 

> I have a sneaking suspicion that ib_srp has zero change of
> working on 32-bit systems (which is what uses this function) so this
> was more about making sure blktests would build when I'm building the
> 32-bit version of my test appliance VM.

What makes you think that ib_srp won't work on 32-bit systems? I don't think
that anyone uses this driver on a 32-bit system. I'm not aware of any aspect
of that driver that restricts it to 64-bit systems only either.

> (For that matter, I've been banging my head against a brick wall
> trying to make the srp tests work in either a KVM or GCE environment,
> even with a 64-bit VM, but that's a different issue.  It's not high
> priority for me, at the moment, but eventually I would like the
> {kvm,gce,android}-xfstest test appliance VM's generated by the
> xfstests-bld repo to be able to run all of blktests.)

Can you be more specific about what didn't work? Were you unable to start the
tests or did a particular test fail?

> What offends me more is that later on there are scopes when len gets
> shadowed with a "ssize_t len;" definition --- I whould have thought
> gcc or clang would have complained bitterly about that, but I guess
> not.

I agree that it would be an improvement to get rid of variable shadowing.
Once that has been done the -Wshadow compiler flag can be added. I will look
into this if nobody else starts looking into this soon.

Bart.

  reply	other threads:[~2018-10-30  6:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 16:15 [PATCH blktests] Fix build failure for discontiguous-io on 32-bit platforms Theodore Ts'o
2018-10-29 16:26 ` Bart Van Assche
2018-10-29 21:08   ` Theodore Y. Ts'o
2018-10-29 21:32     ` Bart Van Assche [this message]
2018-10-29 23:22       ` Theodore Y. Ts'o

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=1540848754.196084.105.camel@acm.org \
    --to=bvanassche@acm.org \
    --cc=linux-block@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.