When sed is asked to inline-edit files, it forgets to close the temporary
file and runs out of descriptors for long command lines (assuming you reset
kern.maxfilesperproc to something sane that's less than the number of files
passed to sed).
subtract one unsigned number from another potentially smaller
one, leading to wraparound (and heap corruption, eventually).
PR: 58813
MFC after: 2 weeks
regular expression as the first argument to a substitute command. If
used to test a sed which (erroneously) evaluates this at translation
time rather than at execution time, the bugged sed is put into an
infinite loop. This mode of failure seems excessive. Such a failing
sed is the Free Software Foundation's sed 3.02.
The specific test was also not being executed for the BSD sed.
Both problems are now fixed.
PR: misc/25585
Submitted by: Walter Briscoe <w.briscoe@ponl.com>
Approved by: schweikh (mentor)
MFC after: 2 weeks
whose true and false clauses were equivalent with a check that we are
not about to stumble off the end of the line.
Reported by: peter
Pointy hat to: fanf
There are two bugs: in the s///g case, the substitution didn't occur
at the end of the line; in the s///N case, the code didn't count
forwards along the line properly. See the sg, s3, s4, and s5 tests
in src/tools/regression/usr.bin/sed/.
Reviewed by: tjr
need to know. Instead, check when we are trying to match a "$" address.
This does not change the way sed processes regular files, but makes it behave
more sensibly when used interactively.
PR: 40101
MFC after: 2 weeks
instead add the newline when the pattern space is printed. Make the `G' and
`H' commands add a newline to the space before the data, remove bogus
addition of newline from `x' command.
PR: 29790, 38195
- original version of code worked incorrectly when more than one
input files were specified - it was moving the last line from the 1st file
to be the first line of the 2nd, last line of the 2nd to be the first
line of the 3rd and so on;
- use mmap()->write() to create temporary file instead of
malloc()->read()->write(), which was not only slower, but also did not
bother to free allocated memory once backup file was created, potentially
leading to memory exhausting when regex is applied to a big file or a large
number of small ones.
