mailing list of musl libc
 help / color / mirror / Atom feed
* [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: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

* 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

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

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git