* [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? [not found] <723b967389be88475206c5afc280c3be02ab677c.camel@klomp.org> @ 2020-10-26 17:28 ` Érico Nogueira 2020-10-26 17:54 ` Max Rees 2020-10-26 19:55 ` Rich Felker 0 siblings, 2 replies; 12+ messages in thread From: Érico Nogueira @ 2020-10-26 17:28 UTC (permalink / raw) To: Mark Wielaard, elfutils-devel, musl; +Cc: Érico Rolim On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote: > Hi Érico, > > On Mon, 2020-10-26 at 12:03 -0300, Érico Nogueira via Elfutils-devel > wrote: > > Do elfutils program actually depend on the extra functionality > > enabled by > > FNM_EXTMATCH? Is changing the flag to have no effect a "bug"? > > Yes. The extended wildcard pattern is relied upon by both > eu-strip with > > --keep-section=SECTION Keep the named section. SECTION is an > extended wildcard pattern. May be given > more than once. > > and eu-elfcompress with > > -n, --name=SECTION SECTION name to (de)compress, SECTION is an > extended wildcard pattern (defaults to > '.?(z)debug*') > > In the eu-strip case it might be reasoned that instead of a > wildcard pattern the user might most of the time simply provide > a section name as is (especially since the option may be given > multiple times). But in the case of eu-elfcompress the > program relies on the default SECTION name being an extended > wildcard pattern. So not supporting FNM_EXTMATCH breaks the > default functionality of eu-elfcompress. > > Cheers, > > Mark Understood, thank you. I'm replying to the musl mailing list as well, then, to hopefully gather more opinions, since I don't know what the best way of solving this would be. Thanks, Érico ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-26 17:28 ` [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? Érico Nogueira @ 2020-10-26 17:54 ` Max Rees 2020-10-26 22:32 ` Mark Wielaard 2020-10-26 19:55 ` Rich Felker 1 sibling, 1 reply; 12+ messages in thread From: Max Rees @ 2020-10-26 17:54 UTC (permalink / raw) To: musl; +Cc: Mark Wielaard, elfutils-devel, Érico Rolim On Mon Oct 26 01:28 PM, Érico Nogueira wrote: > On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote: > > Hi Érico, > > > > On Mon, 2020-10-26 at 12:03 -0300, Érico Nogueira via Elfutils-devel > > wrote: > > > Do elfutils program actually depend on the extra functionality > > > enabled by > > > FNM_EXTMATCH? Is changing the flag to have no effect a "bug"? > > > > Yes. The extended wildcard pattern is relied upon by both > > eu-strip with > > > > --keep-section=SECTION Keep the named section. SECTION is an > > extended wildcard pattern. May be given > > more than once. > > > > and eu-elfcompress with > > > > -n, --name=SECTION SECTION name to (de)compress, SECTION is an > > extended wildcard pattern (defaults to > > '.?(z)debug*') > > > > In the eu-strip case it might be reasoned that instead of a > > wildcard pattern the user might most of the time simply provide > > a section name as is (especially since the option may be given > > multiple times). But in the case of eu-elfcompress the > > program relies on the default SECTION name being an extended > > wildcard pattern. So not supporting FNM_EXTMATCH breaks the > > default functionality of eu-elfcompress. > > > > Cheers, > > > > Mark > > Understood, thank you. I'm replying to the musl mailing list as well, > then, to hopefully gather more opinions, since I don't know what the > best way of solving this would be. > > Thanks, > Érico When I was working on porting elfutils to Adélie (kind of on the backburner right now) I noticed this problem as well. Rather than try to add FNM_EXTMATCH support to musl, I worked around it in elfutils in this manner. 1. I changed the default like so: - add_pattern (".?(z)debug*"); + add_pattern (".debug*"); + add_pattern (".zdebug*"); 2. I updated the corresponding help text to mention this new default. The user could do something similar themselves with multiple "-n" options. Max ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-26 17:54 ` Max Rees @ 2020-10-26 22:32 ` Mark Wielaard 2020-10-26 23:25 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2020-10-26 22:32 UTC (permalink / raw) To: Max Rees, musl; +Cc: elfutils-devel, Érico Rolim Hi Max, On Mon, 2020-10-26 at 13:54 -0400, Max Rees via Elfutils-devel wrote: > On Mon Oct 26 01:28 PM, Érico Nogueira wrote: > > On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote: > > > On Mon, 2020-10-26 at 12:03 -0300, Érico Nogueira via Elfutils- > > > devel > > > wrote: > > > > Do elfutils program actually depend on the extra functionality > > > > enabled by > > > > FNM_EXTMATCH? Is changing the flag to have no effect a "bug"? > > > > > > Yes. The extended wildcard pattern is relied upon by both > > > eu-strip with > > > > > > --keep-section=SECTION Keep the named section. SECTION is an > > > extended wildcard pattern. May be given > > > more than once. > > > > > > and eu-elfcompress with > > > > > > -n, --name=SECTION SECTION name to (de)compress, SECTION is an > > > extended wildcard pattern (defaults to > > > '.?(z)debug*') > > > > > > In the eu-strip case it might be reasoned that instead of a > > > wildcard pattern the user might most of the time simply provide > > > a section name as is (especially since the option may be given > > > multiple times). But in the case of eu-elfcompress the > > > program relies on the default SECTION name being an extended > > > wildcard pattern. So not supporting FNM_EXTMATCH breaks the > > > default functionality of eu-elfcompress. > > > > Understood, thank you. I'm replying to the musl mailing list as well, > > then, to hopefully gather more opinions, since I don't know what the > > best way of solving this would be. > > When I was working on porting elfutils to Adélie (kind of on the > backburner right now) I noticed this problem as well. Rather than try to > add FNM_EXTMATCH support to musl, I worked around it in elfutils in this > manner. > > 1. I changed the default like so: > > - add_pattern (".?(z)debug*"); > + add_pattern (".debug*"); > + add_pattern (".zdebug*"); > > 2. I updated the corresponding help text to mention this new default. > > The user could do something similar themselves with multiple "-n" > options. That is a workaround to get a working build if your libc currently doesn't provide a working fnmatch with FNM_EXTMATCH. But it would still break the interface of the tools that currently accept an extended wildcard pattern. So I think the best way forward is adding FNM_EXTMATCH support to those libcs that don't support it yet (and maybe get it standardized). Cheers, Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-26 22:32 ` Mark Wielaard @ 2020-10-26 23:25 ` Rich Felker 2020-10-27 9:19 ` Florian Weimer 0 siblings, 1 reply; 12+ messages in thread From: Rich Felker @ 2020-10-26 23:25 UTC (permalink / raw) To: Mark Wielaard; +Cc: Max Rees, musl, elfutils-devel, Érico Rolim On Mon, Oct 26, 2020 at 11:32:23PM +0100, Mark Wielaard wrote: > Hi Max, > > On Mon, 2020-10-26 at 13:54 -0400, Max Rees via Elfutils-devel wrote: > > On Mon Oct 26 01:28 PM, Érico Nogueira wrote: > > > On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote: > > > > On Mon, 2020-10-26 at 12:03 -0300, Érico Nogueira via Elfutils- > > > > devel > > > > wrote: > > > > > Do elfutils program actually depend on the extra functionality > > > > > enabled by > > > > > FNM_EXTMATCH? Is changing the flag to have no effect a "bug"? > > > > > > > > Yes. The extended wildcard pattern is relied upon by both > > > > eu-strip with > > > > > > > > --keep-section=SECTION Keep the named section. SECTION is an > > > > extended wildcard pattern. May be given > > > > more than once. > > > > > > > > and eu-elfcompress with > > > > > > > > -n, --name=SECTION SECTION name to (de)compress, SECTION is an > > > > extended wildcard pattern (defaults to > > > > '.?(z)debug*') > > > > > > > > In the eu-strip case it might be reasoned that instead of a > > > > wildcard pattern the user might most of the time simply provide > > > > a section name as is (especially since the option may be given > > > > multiple times). But in the case of eu-elfcompress the > > > > program relies on the default SECTION name being an extended > > > > wildcard pattern. So not supporting FNM_EXTMATCH breaks the > > > > default functionality of eu-elfcompress. > > > > > > Understood, thank you. I'm replying to the musl mailing list as well, > > > then, to hopefully gather more opinions, since I don't know what the > > > best way of solving this would be. > > > > When I was working on porting elfutils to Adélie (kind of on the > > backburner right now) I noticed this problem as well. Rather than try to > > add FNM_EXTMATCH support to musl, I worked around it in elfutils in this > > manner. > > > > 1. I changed the default like so: > > > > - add_pattern (".?(z)debug*"); > > + add_pattern (".debug*"); > > + add_pattern (".zdebug*"); > > > > 2. I updated the corresponding help text to mention this new default. > > > > The user could do something similar themselves with multiple "-n" > > options. > > That is a workaround to get a working build if your libc currently > doesn't provide a working fnmatch with FNM_EXTMATCH. But it would still > break the interface of the tools that currently accept an extended > wildcard pattern. So I think the best way forward is adding > FNM_EXTMATCH support to those libcs that don't support it yet (and > maybe get it standardized). As I stated in my other reply, I'm opposed to that because it does not admit implementation with the same (very desirable) big-O properties, and the "extmatch" syntax is not widely known or widely used. There are very, very few programs actually making use of this, and it would be preferable to see it go away rather than proliferate. Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-26 23:25 ` Rich Felker @ 2020-10-27 9:19 ` Florian Weimer 2020-10-27 15:04 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Florian Weimer @ 2020-10-27 9:19 UTC (permalink / raw) To: Rich Felker Cc: Mark Wielaard, musl, Max Rees, elfutils-devel, Érico Rolim * Rich Felker: > As I stated in my other reply, I'm opposed to that because it does not > admit implementation with the same (very desirable) big-O properties, > and the "extmatch" syntax is not widely known or widely used. The syntax comes from ksh and is used in shell scripts. (bash requires the extglob option to enable it, which makes it easy to search for instances.) Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-27 9:19 ` Florian Weimer @ 2020-10-27 15:04 ` Mark Wielaard 2020-10-27 17:08 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2020-10-27 15:04 UTC (permalink / raw) To: Florian Weimer, Rich Felker Cc: elfutils-devel, musl, Érico Rolim, Max Rees On Tue, 2020-10-27 at 10:19 +0100, Florian Weimer via Elfutils-devel wrote: > * Rich Felker: > > > As I stated in my other reply, I'm opposed to that because it does not > > admit implementation with the same (very desirable) big-O properties, > > and the "extmatch" syntax is not widely known or widely used. > > The syntax comes from ksh and is used in shell scripts. (bash requires > the extglob option to enable it, which makes it easy to search for > instances.) Right, it is also adopted by zsh and some other shells. The big-O properties don't really matter in this case because fnmatch is used on small input strings like file names (or in this case section names). Cheers, Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-27 15:04 ` Mark Wielaard @ 2020-10-27 17:08 ` Rich Felker 2020-10-27 22:19 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Rich Felker @ 2020-10-27 17:08 UTC (permalink / raw) To: Mark Wielaard Cc: Florian Weimer, elfutils-devel, musl, Érico Rolim, Max Rees On Tue, Oct 27, 2020 at 04:04:44PM +0100, Mark Wielaard wrote: > On Tue, 2020-10-27 at 10:19 +0100, Florian Weimer via Elfutils-devel > wrote: > > * Rich Felker: > > > > > As I stated in my other reply, I'm opposed to that because it does not > > > admit implementation with the same (very desirable) big-O properties, > > > and the "extmatch" syntax is not widely known or widely used. > > > > The syntax comes from ksh and is used in shell scripts. (bash requires > > the extglob option to enable it, which makes it easy to search for > > instances.) > > Right, it is also adopted by zsh and some other shells. The big-O > properties don't really matter in this case because fnmatch is used on > small input strings like file names (or in this case section names). 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. Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-27 17:08 ` Rich Felker @ 2020-10-27 22:19 ` Mark Wielaard 2020-10-27 22:25 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2020-10-27 22:19 UTC (permalink / raw) To: Rich Felker Cc: Florian Weimer, musl, Érico Rolim, elfutils-devel, Max Rees Hi Rich, On Tue, Oct 27, 2020 at 01:08:17PM -0400, Rich Felker wrote: > On Tue, Oct 27, 2020 at 04:04:44PM +0100, Mark Wielaard wrote: > > Right, it is also adopted by zsh and some other shells. The big-O > > properties don't really matter in this case because fnmatch is used on > > small input strings like file names (or in this case section names). > > 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. Cheers, Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-27 22:19 ` Mark Wielaard @ 2020-10-27 22:25 ` Rich Felker 2020-10-28 10:05 ` Mark Wielaard 0 siblings, 1 reply; 12+ messages in thread From: Rich Felker @ 2020-10-27 22:25 UTC (permalink / raw) To: Mark Wielaard Cc: Florian Weimer, musl, Érico Rolim, elfutils-devel, Max Rees On Tue, Oct 27, 2020 at 11:19:11PM +0100, Mark Wielaard wrote: > Hi Rich, > > On Tue, Oct 27, 2020 at 01:08:17PM -0400, Rich Felker wrote: > > On Tue, Oct 27, 2020 at 04:04:44PM +0100, Mark Wielaard wrote: > > > Right, it is also adopted by zsh and some other shells. The big-O > > > properties don't really matter in this case because fnmatch is used on > > > small input strings like file names (or in this case section names). > > > > 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. Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-27 22:25 ` Rich Felker @ 2020-10-28 10:05 ` Mark Wielaard 2020-10-28 14:03 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Mark Wielaard @ 2020-10-28 10:05 UTC (permalink / raw) To: Rich Felker Cc: Florian Weimer, musl, Érico Rolim, elfutils-devel, Max Rees 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 pointing out what I believe are technical facts. That extended wildcard patterns are well defined and supported in various context, how Posix 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. 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 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 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. Cheers, Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-28 10:05 ` Mark Wielaard @ 2020-10-28 14:03 ` Rich Felker 0 siblings, 0 replies; 12+ messages in thread From: Rich Felker @ 2020-10-28 14:03 UTC (permalink / raw) To: Mark Wielaard Cc: Florian Weimer, musl, Érico Rolim, elfutils-devel, Max Rees 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? 2020-10-26 17:28 ` [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? Érico Nogueira 2020-10-26 17:54 ` Max Rees @ 2020-10-26 19:55 ` Rich Felker 1 sibling, 0 replies; 12+ messages in thread From: Rich Felker @ 2020-10-26 19:55 UTC (permalink / raw) To: Érico Nogueira; +Cc: Mark Wielaard, elfutils-devel, musl, Érico Rolim On Mon, Oct 26, 2020 at 02:28:59PM -0300, Érico Nogueira wrote: > On Mon Oct 26, 2020 at 3:10 PM -03, Mark Wielaard wrote: > > Hi Érico, > > > > On Mon, 2020-10-26 at 12:03 -0300, Érico Nogueira via Elfutils-devel > > wrote: > > > Do elfutils program actually depend on the extra functionality > > > enabled by > > > FNM_EXTMATCH? Is changing the flag to have no effect a "bug"? > > > > Yes. The extended wildcard pattern is relied upon by both > > eu-strip with > > > > --keep-section=SECTION Keep the named section. SECTION is an > > extended wildcard pattern. May be given > > more than once. > > > > and eu-elfcompress with > > > > -n, --name=SECTION SECTION name to (de)compress, SECTION is an > > extended wildcard pattern (defaults to > > '.?(z)debug*') > > > > In the eu-strip case it might be reasoned that instead of a > > wildcard pattern the user might most of the time simply provide > > a section name as is (especially since the option may be given > > multiple times). But in the case of eu-elfcompress the > > program relies on the default SECTION name being an extended > > wildcard pattern. So not supporting FNM_EXTMATCH breaks the > > default functionality of eu-elfcompress. > > > > Cheers, > > > > Mark > > Understood, thank you. I'm replying to the musl mailing list as well, > then, to hopefully gather more opinions, since I don't know what the > best way of solving this would be. I'm pretty sure we don't want to adopt further fnmatch extensions like this since they seem to affect the big-O's required to do matching and preclude good algorithms. I like Max's solution here with multiple patterns. If elfutils really wants to keep using FNM_EXTMATCH it should probably ship something like gnulib with a replacement fnmatch for systems that don't have it. Rich ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-10-28 14:03 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <723b967389be88475206c5afc280c3be02ab677c.camel@klomp.org> 2020-10-26 17:28 ` [musl] Re: [QUESTION] Which fnmatch() functionality does elfutils depend on? Érico Nogueira 2020-10-26 17:54 ` Max Rees 2020-10-26 22:32 ` Mark Wielaard 2020-10-26 23:25 ` Rich Felker 2020-10-27 9:19 ` Florian Weimer 2020-10-27 15:04 ` Mark Wielaard 2020-10-27 17:08 ` Rich Felker 2020-10-27 22:19 ` Mark Wielaard 2020-10-27 22:25 ` Rich Felker 2020-10-28 10:05 ` Mark Wielaard 2020-10-28 14:03 ` Rich Felker 2020-10-26 19:55 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).