in parentheses. The ?: operator has a remarkably low precedence, so
expressions like (MATCH(foo) && bar) would have an unexpected meaning
w/o the parentheses around MATCH().
Tested with: md5(1)
them are related to the `c' function's need to know if we are at
the actual end of the address range. (It must print the text not
earlier than the whole pattern space was deleted.) It appears the
only sed function with this requirement.
There is `lastaddr' set by applies(), which is to notify the `c'
function, but it can't always help because it's false when we are
hitting the end of file early. There is also a bug in applies()
due to which `lastaddr' isn't set to true on degenerate ranges such
as `$,$' or `N,$' if N appears the last line number.
Handling early EOF condition in applies() could look more logical,
but it would effectively revert sed to the unreasonable behaviour
rev. 1.26 of main.c fought against, as it would require lastline()
be called for each line within each address range. So it's better
to call lastline() only if needed by the `c' function.
Together with this change to sed go regression tests for the bugs
fixed (c1-c3). A basic test of `c' (c0) is also added as it helped
me to spot my own error.
Discussed with: dds
Tested by: the regression tests
MFC after: 1 week
used once on a non-empty pattern space and then again on an empty
pattern space, the second usage restores the pattern space length to
the length that it had when the first "P" was used.
PR: bin/96052
Submitted by: Andrey Zholos <aaz@althenia.net>
MFC after: 7 days
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
