[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230628192836.GV4163@brightrain.aerifal.cx>
Date: Wed, 28 Jun 2023 15:28:36 -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 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.
And to clarify one thing: nothing glibc is doing is wrong. It's fine
for glibc to define the function using off64_t as long as glibc's
underlying definitions of off64_t and loff_t are the same type. This
still matches the published documentation that says loff_t.
I'm not asking for any change by glibc here, just a revert to the man
page change which put a glibc implementation-detail in place of the
equivalent prior-documented public interface.
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.
