[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87sfwmtu2e.fsf@alyssa.is>
Date: Wed, 27 Oct 2021 14:34:49 +0000
From: Alyssa Ross <hi@...ssa.is>
To: Rich Felker <dalias@...c.org>, "(GalaxyMaster)" <galaxy@...nwall.com.au>
Cc: musl@...ts.openwall.com, 2010267516@...com, Kaihang Zhang
<kaihang.zhang@...rtx.com>
Subject: Changes to getmntent
Rich Felker <dalias@...c.org> writes:
> Yes. There are actually several conflicting proposed changes to this
> (frustratingly underspecified, and with bad behavior by glibc)
> function, and so far there's been little engagement between different
> people who want it changed/fixed to resolve the differences. I would
> really like to see from at least one party who wants it changed a
> summary of what the differences are between the different proposals,
> what musl is doing now, and what glibc is doing now, and
> justifications for why their preferred one is okay (including
> capability for applications to recover and not silently use wrong data
> -- "glibc lets them silently use wrong data" isn't a justification).
>
> Rich
Hi, I'm somebody who has proposed changes to getmntent recently, so here
I am specifying what I'd like it to do:
• Lines starting with "#" should be skipped.
• Empty lines should be skipped.
• The fifth and sixth fields should be optional.
All of these changes are things that glibc does today, and musl does
not.
Hopefully it's pretty obvious why the first two are good ideas. As for
the third, I think it's a change to be made because the last two fields
(dump frequency, and pass number on parallel fsck) are obscure and not
required to mount the filesystem, and because fstab(5) says they're
optional.
The approach I've been taking so far is to send a series containing
interspersed patches to libc-test and musl, with the idea that libc-test
could be the place where we specify how genmntent should work. Perhaps,
to accelerate the process of getting everybody on the same page, it
would be better to concentrate on getting tests into libc-test that
describe the behaviour we think musl should have, and once that's done
begin to look at changing musl's implementation to pass the test. Would
that be a good way forward? I'd be happy to kick things off with a
patch to libc-test that tests basic functionality and all the behaviour
changes I'd like to have made, if Rich is happy to go that way.
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
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.
