On Wed, Jun 28, 2023 at 11:21:39AM -0700, Paul Eggert wrote: > On 2023-06-28 10:53, Rich Felker wrote: > >The whole reason loff_t exists is to avoid this problem and make a > >type that's "always full width offset, regardless of _FILE_OFFSET_BITS > >or _LARGEFILE64_SOURCE" to match with the kernel expectation for these > >interfaces. > > Why can't off64_t be that type, as it is in glibc? I'm not seeing > why we need two names for the same type. 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. 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. 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. This is not the case on musl (technically, it's still supported at build-time with explicit -D_LARGEFILE64_SOURCE, but that is slated for removal once known issues are fixed) and we don't want to mislead applications that it is. 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). loff_t encodes no such assumption in its name or specification; it's just "long offset" whatever that is, and an implementation is free (as we do on musl) to just define it as off_t. But more fundamentally, the problem here is that a documented interface was just arbitrarily changed in an incompatible way, with no process or accountability. The documented interface is what applications are supposed to be writing to, and what alternate implementations aiming to be compatible with applications using the interfaces are supposed to match. Changing that out from under us later is Not Nice. Rich
