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.