[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230630233705.GW4163@brightrain.aerifal.cx>
Date: Fri, 30 Jun 2023 19:37:05 -0400
From: Rich Felker <dalias@...c.org>
To: Paul Eggert <eggert@...ucla.edu>
Cc: linux-man@...r.kernel.org, musl@...ts.openwall.com,
libc-alpha@...rceware.org, libc-coord@...ts.openwall.com
Subject: Re: [musl] Re: regression in man pages for interfaces using loff_t
On Fri, Jun 30, 2023 at 12:11:20AM -0700, Paul Eggert wrote:
> 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.
I would love that these functions just take normal off_t. However,
glibc made it so off_t can be 32- or 64-bit depending on
_FILE_OFFSET_BITS, and if it's 32-bit, there is no matching version of
the libc syscall wrappers for these functions. It seems to have been a
conscious choice not to make any.
> 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.
That's the other way around and not related to what I was talking
about.
> 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.
>From a standardization viewpoint, a more general standard does not
want to adopt things from a more specific standard that might have
hidden requirements or tie-in with other parts of the more specific
standard that the more general one would not want to be tied down to.
> >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.)
Noobody's talking about if ISO C would adopt loff_t. I'm talking about
how an interface using a type that's under somebody else's
jurisdiction is problematic to adoption. loff_t having no precedent
except these Linux-introduced functions is why it's not problematic.
However I don't particular like or want to argue "for loff_t". What I
care about is that published interface definitions don't get changed
unilaterally by someone writing docs and made incompatible with
existing implementations.
If we want to work together for something mutually acceptable and
better than loff_t, that'd be fine with me too. But it seems
independent of fixing the immediate regression.
> But anyway this is all moot if we simply document the arguments as
> off_t with a footnote.
This is still changing the documentated signature, which isn't really
nice, and would not be compatible with glibc unless glibc went out of
its way to hide those functions when _FILE_OFFSET_BITS is 32.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
