[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Mar 2023 11:40:38 -0400
From: Rich Felker <dalias@...c.org>
To: Matthias Görgens <matthias.goergens@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [BUG] hasmntopt weirdness
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@...c.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.
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.
