[PATCH] regex-tests, regex: allow glibc re_search behavior

2013-04-10 Thread Dmitry V. Levin
The data passed to re_search by the test for glibc bug 15078 is a multi-character collating element followed by a single character. According to POSIX, "It is unspecified whether a non-matching list expression matches a multi-character collating element that is not matched by any of the expressions

Re: [PATCH 2/2] regex: test for buffer overrun

2013-04-10 Thread Dmitry V. Levin
On Wed, Apr 10, 2013 at 10:07:09PM -0700, Paul Eggert wrote: > On 04/10/2013 09:48 PM, Dmitry V. Levin wrote: > > I think gnulib's tests/test-regex.c should allow glibc's re_search() > > behavior so that various utilities built --without-included-regex > > wouldn't be penalized by test-regex: > >

Re: [PATCH 2/2] regex: test for buffer overrun

2013-04-10 Thread Paul Eggert
On 04/10/2013 09:48 PM, Dmitry V. Levin wrote: > I think gnulib's tests/test-regex.c should allow glibc's re_search() > behavior so that various utilities built --without-included-regex > wouldn't be penalized by test-regex: This looks like a good idea, thanks; but shouldn't gnulib/m4/regex.m4 hav

Re: [PATCH 2/2] regex: test for buffer overrun

2013-04-10 Thread Dmitry V. Levin
On Sun, Mar 31, 2013 at 04:11:41PM +0100, Nix wrote: > On 30 Jan 2013, Paul Eggert spake thusly: > > > + /* This test is from glibc bug 15078. > > + The test case is from Andreas Schwab in > > + > > .

Re: [PATCH 2/2] regex: test for buffer overrun

2013-04-10 Thread Nix
On 10 Apr 2013, Carlos O'Donell verbalised: > On 03/31/2013 11:11 AM, Nix wrote: >> Perhaps this failure is known, but I would say that all is not yet well >> in the state of regex. > > All is *not* well in the state of regex. It is a known issue that there > are some regex bugs and gnulib has tes