Re: [musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t

[Paul Eggert <eggert@cs.ucla.edu>]

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.