Bug 14541

Hey.

I recently looked into behaviour of sed implementations when unusual delimiters were used in:
- context addresses
- s-command


The outcome was, that in my opinion POSIX itself is pretty ambiguous with respect to how it defines these and their parsing and semantics.
See more about that here:
- https://www.austingroupbugs.net/view.php?id=1550
  (not so interesting, just minor clarification proposals)
- https://www.austingroupbugs.net/view.php?id=1551
- https://www.austingroupbugs.net/view.php?id=1556

Especially issue 1551 gives several example where BusyBox' sed behaves considerably different from GNU's sed (which by itself is however not necessarily a bug, especially when even POSIX seems ambiguous).

But there is one case at least, where I think BusyBox' sed is definitely wrong

It's described in detail in:
- https://austingroupbugs.net/view.php?id=1551        (the "main" report and there point (3) )
  https://austingroupbugs.net/view.php?id=1551#c5611  (some additions to point "(3)")

and a tabular overview given in:
- https://austingroupbugs.net/view.php?id=1551#c5612




In short (using BREs as example):

Consider a delimiter is used, that is by itself not a special character (again BREs as example) like  (the non-standard) '+' which is however special when preceded by a '\' (that is itself not quoted).
Same example would work with the (standard) '(', though with different effects.

In BusyBox sed, the following happens:
   $ printf '%s\n' '9+' | busybox sed 's+9\++X+'
   X+
   $ printf '%s\n' '99+' | busybox sed 's+9\++X+'
   X+
   $ printf '%s\n' '999+' | busybox sed 's+9\++X+'
   X+

In GNU sed:
   $ printf '%s\n' '9+' | sed 's+9\++X+'
   X
   $ printf '%s\n' '99+' | sed 's+9\++X+'
   9X
   $ printf '%s\n' '999+' | sed 's+9\++X+'
   99X


In BREs, '+' alone is never special, and the '\+' here is clearly the escape of the delimiter.
Regardless of what POSIX actually means with "literal" (see the discussion in the tickets above), ... there is IMO no way to interpret it like what BusyBox seems to do, which is:

- "un-delimiter" the '+' (because of it's preceding '\' )
- still keep the '\' with respect to the RE and give special meaning to the '+'

That's like "doubling" the effect of the '\'.




The https://austingroupbugs.net/view.php?id=1551#c5611 mentioned above, describes how dangerous this actually is.
Cause even if one uses delimiters, which don't seem "special" in any way, like with:
   $ printf '%s\n' '9' | busybox sed 'sw9\wwXw'
   9
   $ printf '%s\n' '99' | busybox sed 'sw9\wwXw'
   X
   $ printf '%s\n' '999' | busybox sed 'sw9\wwXw'
   X9

BusyBox behaviour get's odd, when that normal character has some special meaning, when preceded by a '\' and when that sequence has than some (non-standard) special meaning (like '\w').

GNU sed handles these like:
   $ printf '%s\n' '99' | sed 'sw9\wwXw'
   99
   $ printf '%s\n' '9w' | sed 'sw9\wwXw'
   X
so it effectively takes the \w ... makes it a non-delimiter (and removes the escaping), being just left with the character 'w' which is by itself literal.



I'd guess that all this might also apply to context addresses in BusyBox sed. Not sure whether EREs are also affect in some weird way.



Thanks,
Chris.