From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32089 invoked from network); 30 Mar 2023 15:40:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Mar 2023 15:40:54 -0000 Received: (qmail 32611 invoked by uid 550); 30 Mar 2023 15:40:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32572 invoked from network); 30 Mar 2023 15:40:50 -0000 Date: Thu, 30 Mar 2023 11:40:38 -0400 From: Rich Felker To: Matthias =?utf-8?Q?G=C3=B6rgens?= Cc: musl@lists.openwall.com Message-ID: <20230330154038.GD4163@brightrain.aerifal.cx> References: <20230330135703.GC4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [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 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.