On 2023-06-28 12:15, Rich Felker wrote:
There's also the problem that off64_t is "exactly 64-bit" which makes
it unsuitable as an interface type for cross-platform functions where
one could imagine the native type being larger (rather horrifying but
possible).
Although we won't have files with 2**63 bytes any time soon, this is the
best argument for preferring "loff_t" to "off64_t".
But come to think of it, it'd be better to document the type simply as
"off_t", with a footnote saying the equivalent of "this assumes that on
32-bit glibc platforms you compile with -DFILE_OFFSET_BITS=64 like any
sane person would." The intent really is off_t here, and that will
remain true even if off_t ever widens past 64 bits.
All the apps I know that use the syscalls in question simply pass
values that fit in off_t to these functions, and this will work
regardless of whether these apps are compiled with 64- or (horrors!)
32-bit off_t. Admittedly the footnote solution would not be perfect, but
it's good enough, and it would sidestep the loff_t vs off64_t confusion.
As for why off64_t is not an appropriate type, it's defined by and
associated with the LFS64 summit and the related intefaces, and
governed by them. Using it makes these interfaces non-standardizable,
because no standard is going to adopt a function whose public
interface depends on another optional thing they don't want to
mandate.
I don't see why not. For example, POSIX-2018 requires int32_t even
though C17 says it's optional. So there's precedent for POSIX adopting a
type that's optional elsewhere.
Also, to POSIX loff_t is just as optional as off64_t is. glibc defines
neither type if the app #defines _POSIX_C_SOURCE as POSIX requires. So
from a standardization viewpoint there's no reason to prefer one type
over the other.
This is exactly the problem why ISO C is stuck with the
broken and unusable fseek/ftell that take long, and hasn't adopted
fseeko/ftello from POSIX -- their public interfaces use the
POSIX-governed type off_t, and as such, ISO C adopting them without
adopting the whole POSIX off_t is out of the question.
I'm not sure what the point is here, as far as standardization goes.
Neither ISO C nor POSIX use loff_t, and neither is likely to ever use
it: ISO C won't even adopt off_t much less loff_t, and POSIX works just
fine with off_t and doesn't need loff_t. (The same goes for off64_t of
course.)
As a particular practical concern, applications performing
configure-like tests may use the existence of an off64_t type to
conclude that the LFS64 API is supported on the system they're being
built on.
Which apps do that?
But anyway this is all moot if we simply document the arguments as off_t
with a footnote.
