Four tests currently fail:
test_ether_line_bad_1() and test_ether_line_bad_2() due to bugs in
ether_line(3).
test_ether_ntohost() and test_ether_hostton() due to not being fully
implemented tests.
on socket buffers is interruptible or not, which detacts the regression I
introduced recently in 7-CURRENT (spotted by alfred). This test passes
in older -CURRENT, and with the as-yet uncommitted sx_xlock_sig and
sblock fix patches.
each file independently from other files. The new semantics are
desired in the most of practical cases, e.g.: delete lines 5-9
from each file.
Keep the previous semantics of -i under a new option, -I, which
uses a single continuous address space covering all files to edit
in-place -- they are too cool to just drop them.
Add regression tests for -i and -I.
Approved by: dds
Compared with: GNU sed
Discussed on: -hackers
MFC after: 2 weeks
[Since the change to strict refcounting for in_multi objects, this test
began to fail; formerly the refcount was a count of the number of requests
for a given address, NOT a count of pointers to the object.]
- Close the new file objects created during socketpair() if the copyout of
the new file descriptors fails.
- Add a test to the socketpair regression test for this edge case.
and had no chance to match it by the 2nd address precisely.
Otherwise the unclosed range would bogusly extend to the end
of stream.
Add a basic regression test for the bug fixed. (This change
also fixes the more complex case 5.3 from `multitest.t'.)
Compared with: SUN and GNU seds
Tested by: regression tests
MFC after: 1 week
in a more reasonable way than BSD sed does: they properly
close the range even if we branched over its end. No doubt,
the range `1,5' should not match lines from 9 through 14.
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
I have verified these with GNU sed 4.1.5 (and in some cases with Solaris
sed) and they are identical, with the following exceptions:
5.3: The result is unspecified and BSD sed behaves differently.
6.3: GNU sed gets it wrong
7.1: GNU sed gets it wrong
7.8: BSD sed gets it wrong
According to IEEE Std 1003.1, 2004 "Whenever the pattern space is
written to standard output or a named file, sed shall immediately
follow it with a <newline>."
An attempt at the same correction might have been made with r1.3,
which is however identical with r1.2.
