* Joanne Koong:
> On Wed, Aug 13, 2025 at 12:21 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>>
>> * Joanne Koong:
>>
>> > On Wed, Aug 13, 2025 at 8:24 AM Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
>> >>
>> >> The FUSE protocol uses struct fuse_write_out to convey the return value of
>> >> copy_file_range, which is restricted to uint32_t. But the COPY_FILE_RANGE
>> >> interface supports a 64-bit size copies and there's no reason why copies
>> >> should be limited to 32-bit.
>> >>
>> >> Introduce a new op COPY_FILE_RANGE_64, which is identical, except the
>> >> number of bytes copied is returned in a 64-bit value.
>> >>
>> >> If the fuse server does not support COPY_FILE_RANGE_64, fall back to
>> >> COPY_FILE_RANGE.
>> >
>> > Is it unacceptable to add a union in struct fuse_write_out that
>> > accepts a uint64_t bytes_copied?
>> > struct fuse_write_out {
>> > union {
>> > struct {
>> > uint32_t size;
>> > uint32_t padding;
>> > };
>> > uint64_t bytes_copied;
>> > };
>> > };
>> >
>> > Maybe a little ugly but that seems backwards-compatible to me and
>> > would prevent needing a new FUSE_COPY_FILE_RANGE64.
>>
>> Even with a capability flag, it encourages the presence of bugs that
>> manifest only on big-endian systems.
>
> Interesting, can you explain how? size would always be accessed
> directly through write_out->size (instead of extracted from the upper
> 32 bits of bytes_copied), so wouldn't the compiler handle the correct
> memory access?
Incorrectly using the size member when bytes_copied is intended and vice
versa would mostly work on little-endian architectures (so hard to spot
during testing), but break spectacularly on big-endian architectures.
Thanks,
Florian
