[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201028140324.GB534@brightrain.aerifal.cx>
Date: Wed, 28 Oct 2020 10:03:25 -0400
From: Rich Felker <dalias@...c.org>
To: Mark Wielaard <mark@...mp.org>
Cc: Florian Weimer <fweimer@...hat.com>, musl@...ts.openwall.com,
Érico Rolim <erico.erc@...il.com>,
elfutils-devel@...rceware.org, Max Rees <maxcrees@...com>
Subject: Re: Re: [QUESTION] Which fnmatch() functionality does
elfutils depend on?
On Wed, Oct 28, 2020 at 11:05:58AM +0100, Mark Wielaard wrote:
> Hi Rich,
>
> On Tue, 2020-10-27 at 18:25 -0400, Rich Felker wrote:
> > On Tue, Oct 27, 2020 at 11:19:11PM +0100, Mark Wielaard wrote:
> > > On Tue, Oct 27, 2020 at 01:08:17PM -0400, Rich Felker wrote:
> > > > They do because they're also in space, unless you want
> > > > exponential-time which is huge even on small inputs, and greater than
> > > > O(1) space requirement means the interface can't satisfy its contract
> > > > to return a conclusive result for valid inputs.
> > >
> > > But that isn't the contract if fnmatch. fnmatch returns 0 for a match
> > > and non-zero for either a non-match or some error. So if your
> > > algorithm hits some error case, like out of memory, returning a
> > > non-zero result is fine.
> > >
> > > I believe the extended wildcard pattern are widely supported and
> > > useful. If you don't want to implement them because they aren't in any
> > > standardized enough yet we can ask the Austin Group to add them to
> > > fnmatch. They have adopted other GNU flags for fnmatch in the past.
> >
> > And I can ask them not to. Your hostility is really unwelcome here.
>
> No hostility intended at all. Please assume postive intend. I was just
"Assume positive intent" is a hostile policy and citing it does not
make you sound better.
> pointing out what I believe are technical facts. That extended wildcard
> patterns are well defined and supported in various context, how Posix
They are not supported by anything near a majority of implementations.
I could not find them anywhere but glibc. The BSDs do not have them
and are probably not interested in them.
> defines the fnmatch contract (which explicitly allows for error
> handling) and that the Austin group has been willing to document and
> specify GNU extensions to various standard functions.
>From a QoI standpoint even if it's not a hard requirement, error
handling is for erroneous expression forms, not "the implementation
failed to do what it was asked to do".
> I am really just trying to help some people who would like musl add
> support for functionality elfutils relies on or find workarounds for
> missing functionality. I realize extended wildcard support through
GNU projects already have an official way to do this: gnulib. If you
want to use glibc extensions of standard functions, you include gnulib
in your project and have the configure script enable replacements for
whichever functions don't have the glibc extension you want on the
host version of the function.
> fnmatch is just one small part of that. There are certainly larger
> issues to overcome. As far as I can see musl doesn't support argp,
> obstack, fts, symbol versions and various on-stack string functions. So
Also all gnulib. The underlying problem here seems to be that elfutils
wants to operate as a GNU project using GNU interfaces, but doesn't
want to ship gnulib to make that portable.
> there is certainly some work to do. But hopefully we can do that
> without taking away any useful features from either project. I don't
> believe anybody is trying to be hostile by trying to make these
> projects work together. I do think it is useful to see if we can
> standardize some of these glibc extensions projects are relying on.
It is not useful to attempt to standardize functions used by a tiny
minority of software, pretty much all from a single "vendor" (GNU).
For the past 5+ years there have been multiple musl-based
distributions shipping thousands if not tens of thousands of packages.
An explicit goal of musl is and always has been making software more
portable by drawing attention to use of non-standard, GNU-specific
functionality.
We have (poorly documented, at the moment, but documented in the
mailing list a long time ago and widely understood) criteria for
inclusion or exclusion of nonstandard interfaces. In order to be
appropriate for inclusion, they need to be either in widespread use or
use in at least some nontrivial amount of important software that
can't be modified to achieve the same thing portably (e.g. with a
drop-in replacement). They also should not have complex interactions
with existing standard functionality that add new implementation
constraints, or be unjustifiably resource-costly. Ideally there should
be precedent on multiple historical systems; if not, they at least
should not have conflicting historical definitions on different
systems.
My personal position on advocating for inclusion of new functionality
in the standard, and I believe this is shared by many in our
community, is that it should follow similar guidelines.
Consensus-based standards processes are about finding common ground in
existing implementations, possibly making minor changes or leaving
minor details unspecified in the process, for the sake of establishing
what programmers can reasonably rely on and maintaining participation
and faith in the process by implementors. "We'll just try to use the
standard to make you do something you're opposed to!" is antithetical
to that process, and when it happens, undermines the whole concept of
standards.
Rich
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.
