[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Jul 2023 16:06:35 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: Rich Felker <dalias@...c.org>
Cc: libc-coord@...ts.openwall.com, linux-man@...r.kernel.org,
musl@...ts.openwall.com, libc-alpha@...rceware.org
Subject: Re: [musl] Re: Re: [musl] Re: regression in man pages
for interfaces using loff_t
On 2023-07-01 07:32, Rich Felker wrote:
> These are not "new APIs" from the standpoint of glibc, which already
> had them in 32-bit-off_t API profiles and can't be expected just to
> remove them.
That's OK, as the proposed doc change doesn't remove the new APIs.
By "new APIs" I meant off_t-oriented APIs newer than the fallout from
the LFS mess of the 1990s; these APIs are not that new to people versed
with the Linux kernel.
> I'm all for using off_t in new interfaces. But unless glibc folks
> agree, I am not for redefining interface types in a way that breaks
> one of their supported profile
The change I just proposed doesn't invalidate any part of the glibc
implementation, or of musl for that matter. They're both fine as-is.
(The previous doc change - the one that prompted your objection - did
invalidate the musl implementation, and that is one thing the proposed
change fixes.)
Just to be clear, the proposed change is merely trying to document the
current situation more carefully, so that programmers who are not expert
in this area are better aware about the unlikely gotchas. It doesn't
attempt to change or invalidate any existing implementation.
> 1. The spec was that apps declare loff_t objects and pass pointers to
> those to some of the interfaces. That works on all existing
> implementations and profiles.
The fact that it worked was merely an accident, as people didn't follow
that old spec. None of the apps I know of use loff_t for these APIs.
The spec for these APIs should never have suggested using an oddball
type like loff_t that actual app code typically doesn't use. The spec
should instead suggest working code, code that is what people would or
should actually write. The proposed patch does this.
> 2. The spec was silently changed to be that apps declare off64_t
> objects and pass those instead. This breaks on musl which
> intentionally does not have LFS64 types/interfaces.
The proposed patch fixes this.
> 3. Under your proposal, the spec is that apps declare off_t objects
> and pass pointers to those. This produces a pointer type mismatch,
> and buffer overflow, if building with glibc and (still default)
> _FILE_OFFSET_BITS=32.
There's a loud compile-time error if you make such a mistake. It's the
came sort of compile-time error you get if you misuse any glibc API by
passing a wrong pointer type. If these compile-time errors are good
enough for the rest of the glibc API, they're good enough here.
> Of course glibc could try to remedy this by somehow masking these
> functions when _FILE_OFFSET_BITS=32 so they can't get used.
I don't see why that is necessary, or even a good idea. Many (in my
experience most) calls to these functions will work fine even with
_FILE_OFFSET_BITS=32, because they're passing a null pointer. I don't
see why we'd want to prohibit this.
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.
