APR 0.9.x can't change the size of apr_off_t, but it's still useful to
be able to use O_LARGEFILE in a few specific cases on LFS platforms when
the application knows it is safe: to allow writing >2Gb log files in
particular. It's not safe to use in general, since {f,l,}stat() will
fail on a >2gb file with a 32-bit off_t, so needs to come with a big
warning sign.
So for any file where the app will only open it or append to it, it can safely specify APR_LARGEFILE and the right thing will happen, with big "log" files where possible.
+1
[In the hope that this isn't really needed for 1.0]
With APR 1.0, what is the reason for not having the same flag? Isn't there still the same situation where APR 1.0 will usually be built without large file support, and a random user can't rebuild APR with LFS without breaking existing apps, but may still want to support large "log" files?
Having APR always use long file offsets when interacting with the app and for non-LFS builds doing the ugly conversion (and possibly generating the EFBIG) when interacting with the OS seems to be a way to make everything work without APR binary compatibility issues. I'm not suggesting that is the way to go, but unless there is some sort of solution it seems that we have an equivalent need for APR_LARGEFILE flag with APR 1.0.
(Related trivia: Maybe README.dev needs notes on large file support, starting with the basic Unix requirement you outlined in a PR yesterday
export CPPFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ./configure
and then having folks add comments on platforms where it has been tested and/or where there are special considerations.)
