[Bug 209352] Bug in usr.bin/sed

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209352

            Bug ID: 209352
           Summary: Bug in usr.bin/sed
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: pfg at FreeBSD.org

This was noted from the openbsd-bugs list :

(Reply from Tim Chase 2016-04-24)...
Can be simplified to the test-case

 $ echo a,a,a,a,a | sed -r 's/\<.,/X&/g'
 Xa,a,Xa,a,a
 $ echo a,a,a,a,a | gsed -r 's/\<.,/X&/g'
 Xa,Xa,Xa,Xa,a

It appears the determination of "\<" can get thrown off when the
character preceding it is part of a replacement.
_____

I have reproduced it with the sed in FreeBSD
_____

There is a solution candidate in openbsd-tech, but the patch doesn't apply
directly:

>From  Martijn van Duren - 2016-05-04)
For those interested: The problem comes from the fact that the string
pointer increments to the end of the previous match and is then called
with the REG_NOTBOL. The REG_NOTBOL combined with a match at the begin
of the string causes our regex library to treat the word as not begin of
word.
The TRE implementation does the reverse and treats this case as if it
always is begin of word. This causes a similar bug under MacOS:
$ echo 'foo foofoo' | sed -E 's/\<foo/bar/g'
bar barbar

I've solved this problem by converting sed to use REG_STARTEND more
explicitly. Although this isn't a POSIX specified flag, it is already
used by sed and shouldn't be a problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.