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;
... but I really don't think the user would ever send a length >
2**32, and 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.
(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.)
If folks have strong opinions about what's the best way to fix this,
I'm happy to adjust the patch. (I personally don't care that much).
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 didn't want to make that many clean up changes, especially
since I'm not in a position to test any changes that I make, since as
I mentioned the srp blktests are failing miserably for me.
- Ted
