Johannes Meixner wrote: > Hello Jim, > > On Jun 16 10:44 Jim Meyering wrote (excerpt): >>>> Thus, if we go this route, we are effectively saying >>>> that people who want self-consistent regex-handling >>>> in our tools must build with --with-included-regex or end >>>> up causing subtle problems. > ... >>> It goes like this (at least for gawk, grep and sed): >>> >>> change how dfa.c interprets ranges like [a-z] >>> change how gnulib's reg* code handles ranges >>> >>> Always use the included regex code (the one from gnulib), >>> so that its interpretation is consistent with that of dfa.c. >>> >>> Grep's current upstream default is to build --with-included-regex, >>> which makes grep use glibc's regex code.
Hi Johannes, > Isn't there a typo? > > Shouldn't it read > "Grep's current upstream default is to build --without-included-regex, > which makes grep use glibc's regex code." Yes, you're right. Thanks for pointing that out. > At leats for grep-2.7 "configure --help" shows me: > ----------------------------------------------------------------------- > --without-included-regex > don't compile regex; this is the default on systems > with recent-enough versions of the GNU C Library > (use with caution on other systems). > ----------------------------------------------------------------------- > > Or do I misunderstand something here? > >>> To make this proposed change go through, that configure-time option would >>> have to be eliminated, so that we always build with the gnulib-provided >>> regex code. Of course, if glibc ever changes, we can detect that and >>> automatically prefer it when possible. >> >> For the record, at least Fedora's grep and sed both build >> --without-included-regex, so would be affected. > > Same for openSUSE and all the "Suse Linux Enterprise" products. > > > Kind Regards > Johannes Meixner
