BUG: Use large file fallocate on 32 bit linux platforms

[snogge]

In spite of all of the required preprocessor directives set to use UNIX Large File Support, multiarray/convert.c still used the fallocate version with 32bit offset_t, at least with glibc.

glibc provides both 32bit and 64bit fallocate by silently using the fallocate64 symbol instead of fallocate when -D_FILE_OFFSET_BITS=64 is set. Using a local prototype for fallocate instead of the fcntl.h header in multiarray/convert.c circumvented the glibc redirect.

A similar but not identical PR #25630 has been pushed for 1.26.X.

[snogge]

Please note that this patch is slightly different from the one in #25630 (meant for 1.26 branch). This patch wont work on 1.26, while the 1.26 version probably works on main.

[ngoldbaum]

That's fine, @charris can take note after this is merged.

I think this hasn't gotten any review so far because the PR description doesn't contain any context for what the issue is and what exactly this is fixing. There also isn't a test.

[snogge]

I've updated the description, I hope that helps.
I don't know how to write a test for this. I discovered the problem when scanning all binaries built with the Yocto Project for files that still used the 32bit symbols even with the LFS defines set globally. I don't know of any actual program that have problems because of this.

[ngoldbaum]

Thanks for the context, I'll make sure this gets brought up at the next triage meeting.

[mattip]

We discussed this at a triage meeting, reviewed the code as well as we could with no test, and decided it makes sense.

[mattip]

Thanks @snogge

[snogge]

Thank you for quick turnaround.