* [musl] [BUG] hasmntopt weirdness
@ 2023-03-30 10:02 Matthias Görgens
2023-03-30 13:57 ` Rich Felker
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Görgens @ 2023-03-30 10:02 UTC (permalink / raw)
To: musl
Musl's `hasmntopt` is a bit weird.
For example, my `/proc/mounts` contains the following line:
shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k,inode64 0 0
If I run `hasmntopt(entp, "suid")` on that entry with glibc, I get
NULL. In musl I get: "suid,nodev,noexec,relatime,size=65536k,inode64".
Do we have a spec for what should happen? I can find multiple
descriptions online, some of them would allow what musl does, but not
all. I don't know what's authoritative.
Arguably the musl behaviour is a bit silly by itself, and would
actively cause bugs for someone porting programs from glibc.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [musl] [BUG] hasmntopt weirdness
2023-03-30 10:02 [musl] [BUG] hasmntopt weirdness Matthias Görgens
@ 2023-03-30 13:57 ` Rich Felker
2023-03-30 14:47 ` Matthias Görgens
0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2023-03-30 13:57 UTC (permalink / raw)
To: Matthias Görgens; +Cc: musl
On Thu, Mar 30, 2023 at 06:02:43PM +0800, Matthias Görgens wrote:
> Musl's `hasmntopt` is a bit weird.
>
> For example, my `/proc/mounts` contains the following line:
>
> shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k,inode64 0 0
>
> If I run `hasmntopt(entp, "suid")` on that entry with glibc, I get
> NULL. In musl I get: "suid,nodev,noexec,relatime,size=65536k,inode64".
>
> Do we have a spec for what should happen? I can find multiple
> descriptions online, some of them would allow what musl does, but not
> all. I don't know what's authoritative.
>
> Arguably the musl behaviour is a bit silly by itself, and would
> actively cause bugs for someone porting programs from glibc.
I'm pretty sure it was agreed upon at one point that this was a bug,
but never pursued further.
From what I remember, I think hasmntopt needs to check that the match
found is at the start or immediately follows a comma (unless there is
some awful way to embed literal commas) and that it's followed by an
equals sign, comma, or nul terminator. Does this sound correct?
There's not really a need to use strstr to do this, but it might still
be the simplest implementation.
Rich
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [musl] [BUG] hasmntopt weirdness
2023-03-30 13:57 ` Rich Felker
@ 2023-03-30 14:47 ` Matthias Görgens
2023-03-30 15:40 ` Rich Felker
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Görgens @ 2023-03-30 14:47 UTC (permalink / raw)
To: musl
On Thu, 30 Mar 2023 at 21:57, Rich Felker <dalias@libc.org> wrote:
> I'm pretty sure it was agreed upon at one point that this was a bug,
> but never pursued further.
OK, that's good to know!
> From what I remember, I think hasmntopt needs to check that the match
> found is at the start or immediately follows a comma (unless there is
> some awful way to embed literal commas) and that it's followed by an
> equals sign, comma, or nul terminator. Does this sound correct?
For what it's worth, that's close to what glibc does.
Sorry, I'm new to this: Is there a spec to these things, or do we just copy what
the other C standard libraries are doing?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [musl] [BUG] hasmntopt weirdness
2023-03-30 14:47 ` Matthias Görgens
@ 2023-03-30 15:40 ` Rich Felker
0 siblings, 0 replies; 4+ messages in thread
From: Rich Felker @ 2023-03-30 15:40 UTC (permalink / raw)
To: Matthias Görgens; +Cc: musl
On Thu, Mar 30, 2023 at 10:47:27PM +0800, Matthias Görgens wrote:
> On Thu, 30 Mar 2023 at 21:57, Rich Felker <dalias@libc.org> wrote:
> > I'm pretty sure it was agreed upon at one point that this was a bug,
> > but never pursued further.
>
> OK, that's good to know!
>
> > From what I remember, I think hasmntopt needs to check that the match
> > found is at the start or immediately follows a comma (unless there is
> > some awful way to embed literal commas) and that it's followed by an
> > equals sign, comma, or nul terminator. Does this sound correct?
>
> For what it's worth, that's close to what glibc does.
>
> Sorry, I'm new to this: Is there a spec to these things, or do we just copy what
> the other C standard libraries are doing?
For standard functions, there is a spec.
For nonstandard ones, generally no, and that's why musl frowns on
them. We have to basically do what the standardization process would
have done: looking at historical practice and whether the interface
and behavior was sufficiently consistent across different historical
systems with the nonstandard extension that we can work out a behavior
that's not conflicting with what applications might expect.
When this is difficult or impossible, that's a strong indication that
we shouldn't adopt the interface at all. But due to historical
mistakes (not doing sufficient analysis to apply these principles), we
let a few things in we shouldn't have.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-03-30 15:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-30 10:02 [musl] [BUG] hasmntopt weirdness Matthias Görgens
2023-03-30 13:57 ` Rich Felker
2023-03-30 14:47 ` Matthias Görgens
2023-03-30 15:40 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).