Age | Commit message (Collapse) | Author |
|
This is a 15 year old freebsd extension (presumably thus also available on
MacOS) that glibc adopted in 2004, uClibc adopted in 2005, and bionic
supports. The only thing that DOESN'T support it is musl, once again
because its maintainer explicitly decided not to
(https://www.openwall.com/lists/musl/2013/01/15/26), so add an #ifdef
to let musl stay uniquely broken. (It'll stop at first NUL, everything
else can match NULs).
Finally fixes "s/x/y/g on a megabyte line of x's takes forever" issue.
|
|
Very few places actually check for errors from emit, and I actually see
the same endless loop from "sed (GNU sed) 4.4" on current Debian, so I'm
not sure this isn't Broken As Designed, but an endless loop spewing
"short write" (or saying nothing, in the case of GNU sed) really doesn't
feel like useful behavior in face of EPIPE, which really isn't going to
fix itself. Certainly not being able to run the sed tests to completion
is pretty annoying --- which is why, unless we remove this test as
invalid, we should probably also add a SKIP_HOST=1 to the "b loop" test.
Note that even with this fix you'll see the error twice:
sed: short write: Broken pipe
sed: short write: Broken pipe
Once from the first = command to fail, and then another from the !FLAG(n)
flush of the pattern space.
|
|
The test for \N where N was larger than the number of capturing groups
in the regular expression was incorrect, and firing for cases such as
matching __(ARM_)?NR_([a-z]*) against __NR_read, where the first group is
empty (because it failed to match) but the second group did match "read".
Use regex_t's re_nsub for the error check, and treat rm_so == -1 as a
signal to just copy nothing into the result.
(Found trying to build minijail in AOSP.)
|
|
Used to construct SELinux policies in the AOSP build.
I left loopfiles_lines with its hard-coded '\n' because although cut(1)
also has a -z option, I can't find any case where it's used in any of
the codebases searchable by me. (And fmt(1), the other user, doesn't
even have the option.) YAGNI.
Bug: http://b/122744241
|
|
For a definition of "fix" that's even _more_ of a deviation from posix, but
matches what debian does...
|
|
Bug: http://b/122744241
|
|
|
|
Or more accurately, s@[[:space:]@]@replace@ which can't treat the @ in
[] as a delimiter but has to know about nested [[]] to make that decision.
|
|
|
|
|
|
effect of "sed -e 'a\'" with no trailing line). But there's an actual user,
and it's not hard to implement, and it's not hard to implement, and there
isn't an obvious _other_ way to do it, so add the behavior and a test for it.
Fix some bad/missing comments while I was there, and add a couple TODOs.
|
|
The tests/*.test files shouldn't explicitly exit, because they are
sourced in scripts/test.sh. No tests after sed were being run.
|
|
Found by afl-fuzz.
|
|
|
|
It uses a sed expression that assumes you can escape - to use it as a literal
(you can't, it has to be first or last char of the range), and assumes
you have to escape delimiters in sed [] context (you don't), and/or that
non-printf escapes become the literal character (they don't, the backslash
is preserved as a literal), meaning it winds up doing "s/[\-\]//" which is
a length 1 range, which is officially undefined behavior according to posix,
and regcomp errors out.
But if we don't accept it (like other implementations do) the perl build
breaks. So collapse [A-A] into just [A].
Testcae taken from perl 5.22.0 file Makefile.SH line 8.
(While we're at it, remove an unused argument from a function.)
|
|
|
|
|
|
|
|
an extra newline because the test for whether we have an existing string to
append a newline to was checking if struct step had data appended to it,
and the /x/ regex is data appended to it. Change test to check for null
terminator at ->arg1 offset.
|
|
|
|
|
|
the same command.)
|
|
|
|
anything left in the line, and more tests.
|
|
|
|
|
|
|
|
|
|
Only good for TEST_HOST=1 at the moment because the test infrastructure itself
depends on sed, so if an unfinished sed is in the $PATH it goes boing. But
hey, corner cases!
I have... more.
|