Are fgetpos, fsetpos, fseeko and ftello broken with _FILE_OFFSET_BITS=64 when __ANDROID_API__ < 24?

[fornwall]

When using _FILE_OFFSET_BITS=64 with unified headers on 32-bit platforms <sys/types.h> declares off_t to be 64 bits, while otherwise these platforms uses a 32-bit off_t.

Then <stdio.h> declares:

typedef off_t fpos_t;
...
#if defined(__USE_FILE_OFFSET64) && __ANDROID_API__ >= __ANDROID_API_N__
int fgetpos(FILE*, fpos_t*) __RENAME(fgetpos64);
int fsetpos(FILE*, const fpos_t*) __RENAME(fsetpos64);
int fseeko(FILE*, off_t, int) __RENAME(fseeko64);
off_t ftello(FILE*) __RENAME(ftello64);
...
#else
int fgetpos(FILE*, fpos_t*);
int fsetpos(FILE*, const fpos_t*);
int fseeko(FILE*, off_t, int);
off_t ftello(FILE*);
...
#endif

When targeting 32-bit platforms pre-N (that is, __ANDROID_API__ >= __ANDROID_API_N__ is false), and using __USE_FILE_OFFSET64, won't this result in problems in that the compiler emits calls to fgetpos/fsetpos/fseeko/ftello with 64-bit off_t arguments while the implementations in libc expect off_t to be 32-bit?

[alexcohn]

I am afraid it's a known bug not only with Unified Headers

[fornwall]

I am afraid it's a known bug not only with Unified Headers

Before unified headers off_t/fpos_t was always 32 bit in size, so the headers never incorrectly declared that fgetpos/fsetpos/fseeko/ftello took 64 bit sized arguments, which can happen now when __USE_FILE_OFFSET64 is set with unified headers.

I guess it would be more correct to declare them as taking the 32-bit __kernel_off_t
in the case when defined(__USE_FILE_OFFSET64) && __ANDROID_API__ < __ANDROID_API_N__?

[alexcohn]

I don't remember the details, but some talented developer succeeded to bend the headers for NDK r.11 so that pread() received a 64-bit position and we were all puzzled for a while why the API was only working as expected for offset=0.

[enh]

this was changed by me in #333 as a follow up to #332.

looking back, i think we made the wrong decision on those bugs. (maybe by false analogy to #324 which still seems fine, albeit unrelated.) we should have said "this failure to compile is correct: you asked for _FILE_OFFSET_BITS=64 and then used a function that takes an off_t but isn't available in a 64-bit variant at the API level you're targeting". it's early in the morning on the first day of work for us this week, so i reserve the right to change my mind when i'm fully awake, but right now i read my checkin comment...

Only rename fgetpos/fsetpos/fseeko/ftello/funopen if we're N or newer.
Without this, setting __FILE_OFFSET_BITS to 64 and targeting pre-L
made these functions entirely unavailable.

...and think "yes, it does, as it should since versions that took off64_t didn't exist back then".

i think the fix here is to revert the two changes (the mmap.h one and the "everything else" one), and call the original bugs "working as intended". i honestly have no idea what we were thinking when we made these changes, so i'll make sure i get a second opinion first!

[enh]

it's much later in the day, and i still think we were insane to have made these changes. i have no idea what we were thinking. https://android-review.googlesource.com/429481 basically backs them out --- the problem of "my code doesn't compile because this function doesn't exist" is much better than "my code compiles but fails at run time because the function really didn't exist", and easier to debug!

[koying]

I'm afraid this fix produced an unwanted side-effect in 15c if you #include <cstdio> with __USE_FILE_OFFSET64

/opt/android-dev/android-toolchain-arm-21-r15c/include/c++/4.9.x/cstdio:107:11: error: '::fgetpos' has not been declared
   using ::fgetpos;
           ^
/opt/android-dev/android-toolchain-arm-21-r15c/include/c++/4.9.x/cstdio:117:11: error: '::fsetpos' has not been declared
   using ::fsetpos;
           ^

[DanAlbert]

(filed a new bug rather than continuing on this one, since it's not quite the same problem, #480)