Rich Felker 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.