[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230701133652.GF3630668@port70.net>
Date: Sat, 1 Jul 2023 15:36:52 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Paul Eggert <eggert@...ucla.edu>
Cc: libc-coord@...ts.openwall.com, Rich Felker <dalias@...c.org>,
linux-man@...r.kernel.org, musl@...ts.openwall.com,
libc-alpha@...rceware.org
Subject: Re: [libc-coord] Re: Re: regression in man pages for
interfaces using loff_t
* Paul Eggert <eggert@...ucla.edu> [2023-07-01 00:24:27 -0700]:
> On 2023-06-30 16:37, Rich Felker wrote:
> > 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.
>
> I don't see any incompatibility with glibc and the changes I proposed. The
> changes merely weaken the spec in the man pages in an area where the spec
> should be weakened. glibc is compatible with the spec before it was changed
> to use off64_t, it's compatible with the spec now that it uses off64_t, and
> it would continue to be compatible with the spec if the proposed changes are
> adopted.
loff_t * can be incompatible with off64_t * as well as off_t *.
the documentation change can break the api of an implementation,
it is not weakening the spec.
(it can also break abi if loff_t has different abi than off64_t. two
integer types can have same range, representation and syscall argument
passing abi, but different libc abi and different c++ abi)
i don't think you can claim that glibc is compatible either way, as
a future target port can define loff_t differently than off64_t.
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.
