Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Jun 2023 15:28:36 -0400
From: Rich Felker <>
To: Paul Eggert <>
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.


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.