vfs_btrfs: fix compile on 32-bit platforms and the issues with getting simple changes reviewed.

[Rusty Russell]

Andrew Bartlett <abartlet at samba.org> writes:
> On Sat, 2013-03-23 at 09:40 +0100, Rusty Russell wrote:
>
>> commit fd6d0361d6fef5f8175967ddbae4a2b1d79dfcad
>> Author: Rusty Russell <rusty at rustcorp.com.au>
>> Date:   Sat Mar 23 17:26:57 2013 +1030
>> 
>>     vfs_btrfs: fix compile on 32-bit platforms.
>>     
>>     uint64_t are not unsigned longs on 32-bit platforms:
>>     
>>     [3265/3996] Compiling source3/modules/vfs_btrfs.c
>>     ../source3/modules/vfs_btrfs.c: In function ‘btrfs_copy_chunk_send’:
>>     ../source3/modules/vfs_btrfs.c:118:3: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Werror=format]
>>     ../source3/modules/vfs_btrfs.c:118:3: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘int64_t’ [-Werror=format]
>>     ../source3/modules/vfs_btrfs.c:118:3: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format]
>>     ../source3/modules/vfs_btrfs.c:118:3: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 7 has type ‘uint64_t’ [-Werror=format]
>>     ../source3/modules/vfs_btrfs.c: In function ‘btrfs_copy_chunk_recv’:
>>     ../source3/modules/vfs_btrfs.c:180:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘off_t’ [-Werror=format]
>>     cc1: some warnings being treated as errors
>>     
>>     Signed-off-by: Rusty Russell <rusty at rustcorp.com.au>
>
> Rusty,
>
> This looks wrong, and I had an alternative patch awaiting review on the
> mailing list since Wednesday.  In particular the difference is that we
> cast to long long, and change the format string, because these
> parameters can be > 4GB, particularly the offset.

Gah, sorry, I should have checked the ml first.  I just assumed that if
anyone else cared, it would have been fixed.

> Perhaps revert this, and merge the patch I was waiting for review on?
>
> I note with irony that this shows up the worst of our current voluntary
> review situation.  I'm trying hard to ask for reviews, but they are hard
> to come by, even for simple build errors.  I probably should have taken
> metze's comments as a positive review, or have asked for a
> clarification, but in the meantime you and others remain put out.  That
> in turn made you put this in without review - because it was getting in
> your way, and reviews are voluntary - and we need to go over it again. 

OK, but let's not compound the problem by spending *more* time on a
trivial issue.

I have reverted mine, reviewed and applied yours.  

Thanks,
Rusty.