mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Paul Eggert <>
To: Rich Felker <>
Subject: Re: [musl] Re: [libc-coord] Re: [musl] Re: regression in man pages for interfaces using loff_t
Date: Sat, 1 Jul 2023 16:06:35 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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)

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.

  parent reply	other threads:[~2023-07-01 23:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 17:53 [musl] " Rich Felker
2023-06-28 18:21 ` [musl] " Paul Eggert
2023-06-28 19:15   ` Rich Felker
2023-06-30  7:11     ` Paul Eggert
2023-06-30  8:02       ` [musl] Re: [libc-coord] " Jonathan Wakely
2023-06-30  8:14         ` Jonathan Wakely
2023-06-30  8:30           ` Sam James
2023-06-30 19:44         ` Paul Eggert
2023-07-02  1:18           ` A. Wilcox
2023-07-02 19:21             ` Paul Eggert
2023-07-03 18:16               ` Jakub Wilk
2023-07-03 21:35                 ` Paul Eggert
2023-07-08 17:03                   ` Alejandro Colomar
2023-07-09  6:07                     ` [musl] [PATCH v4] off64_t: prefer off_t for splice, etc Paul Eggert
2023-07-09  6:16                       ` [musl] Re: [libc-coord] " Sam James
2023-07-15 15:08                         ` Alejandro Colomar
2023-07-15 18:35                           ` Rich Felker
2023-07-15 20:01                             ` Paul Eggert
2023-07-16  0:35                             ` Alejandro Colomar
2023-07-16  0:39                               ` Alejandro Colomar
2023-06-30 23:37       ` [musl] Re: regression in man pages for interfaces using loff_t Rich Felker
2023-07-01  7:24         ` [musl] Re: [libc-coord] " Paul Eggert
2023-07-01 13:36           ` Szabolcs Nagy
2023-07-01 23:02             ` Paul Eggert
2023-07-01 14:32           ` Rich Felker
2023-07-01 18:45             ` Alejandro Colomar
2023-07-01 23:06             ` Paul Eggert [this message]
2023-06-28 19:19   ` Szabolcs Nagy
2023-06-28 19:28   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).