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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux