Seeking advise on most portable way to detect 64-bit off_t

[Aliaksey Kandratsenka]

Hi.

In gperftools we have the feature to hook mmap calls which works by
interposing over glibc's mmap. So it has to deal with off_t complexities.
We don't use that offset argument, other than just passing it to real mmap
implementation. I am also trying to support different Linux libc-s just for
completeness. And musl being new enough and wise enough has always had
64-bit off_t (bionic hasn't and there is really no excuse...)

So with that I need some means to detect 32-bit off_t that works across
multiple libcs and has the highest hope of working in the future.

By looking around, I choose to detect 32-bit-ness of off_t by looking at
semi-obscure define _POSIX_V7_ILP32_OFF32:
https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275

It does seem to do the right thing across implementations I checked. Well
mostly.

These days, Debian folk are doing a massive 64-bit time_t transition (which
also includes mass-enabling 64-bit off_t, at last) and they're rebuilding
everything with _FILE_OFFSET_BITS=64. And my "approach" fails.
https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log

Glibc doesn't adjust _POSIX_V7_ILP32_{BIGOFF,OFF32} defines based on
_FILE_OFFSET_BITS. Perhaps rightly so. But with that situation I need some
other, and hopefully more robust means to detect off_t width.

I am thinking of 3 options:

* Keep _POSIX_V7 thingy but also add a check for _FILE_OFFSET_BITS == 64.
And then behave as if off_t is 32-bit.
* #undef _FILE_OFFSET_BITS at the first line in mmap_hooks.cc. It will
cause glibc on those legacy 32-bit off_t systems to define 32-bit off_t and
give me right defines and my code will define mmap symbol with 32-bit
offset arg and mmap64 symbol with 64-bit offset. And thus matching glibc.
* just manually hardcode knowledge that glibc +
{i386,arm{el,hf},mips32,ppc32} has 32-bit off_t. But that leaves the
question of how to deal with e.g. bionic (well, I could in principle say,
bionic already being broken enough is only supported for 64-bit systems,
which is where android systems are moving anyways)

I am looking for any comments or suggestions. Particularly I'd like my fix
to be robust w.r.t. any further glibc evolution.