[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.
effective group ID or to group ID of its parent directory.
- Add some comments from POSIX.
- Verify that after successful O_TRUNC open, size is equal to 0.
he is the file's owner, he can't set set-gid bit.
POSIX requires to return 0 and clear the bit, but FreeBSD returns
EPERM for UFS in such case. For now do the same in ZFS.
Almost all regression tests are based on very flexible fstest tool.
They verify correctness (POSIX conformance) of almost all file
system-related system calls.
The motivation behind this work is my ZFS port and POSIX, who doesn't
provide free test suites.
Runs on: FreeBSD/UFS, FreeBSD/ZFS, Solaris/UFS, Solaris/ZFS
To try it out:
# cd fstest
# make
# find tests/* -type d | xargs prove
various types, as well as pipes and fifos for good measure. RELENG_6
currently passes all of these tests, but 7-CURRENT fails 0-byte writes
and sends on all stream socket types (and fifos, as they are based on
stream sockets).
Bumped into by: peter
Diagnosed by: jhb
Problem of: andre
to floating-point, the result is a quiet NaN. The current implementation
may return a signaling NaN, and the vendor has no plans for changing this,
for reasons explained in the comment I added.
mbuf is dropped, to preserve the invariant in the PR_ADDR case.
Add a regression test to detect this condition, but do not hook it
up to the build for now.
PR: kern/38495
Submitted by: James Juran
Reviewed by: sam, rwatson
Obtained from: NetBSD
MFC after: 2 weeks
