Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
While big, the change was meant to have no effect on behavior and instead
so far we have found two regressions: one in the etcupdate tests and
another one in the games/openttd port[1].
Revert to a known working state. We will likely have to split the patch in
functional parts before bringing back the changes.
PR: 195929
Reported by: danfe, madpilot [1]
Summarizing the findings in the OpenBSD list:
This solves a reproduceable issue with very recent Mesa where REG_NOTBOL
combined with a match at the begin of the string causes our regex library
to treat the word as not begin of word.
Thanks to Martijn van Duren and Ingo Schwarze for taking the time to
solve this in the least invasive way.
PR: 209352, 209387
Taken from: openbsd-tech (Martijn van Duren)
MFC after: 1 month
Rewrite the main loop of the "sed s/..." command, shortening it by ten
lines and simplifying it by removing the switch statement implementing
/g, /1, and /2 separately and repetitively.
This will be needed to bring a fix from OpenBSD later.
Obtained from: OpenBSD (schwarze CVS Rev. 1.18)
MFC after: 3 weeks
While here, change how we check if the current line is the last one.
Before, we just checked if there were more files after the current one.
Now, we check the actual content of those files: they files may not have
a line at all. This matches the definition of the "last line" by the
Open Group.
The new behavior is closer to GNU sed.
PR: 160745
Phabric: https://phabric.freebsd.org/D431
Reviewed by: jilles
Approved by: jilles
Exp-run by: antoine
1) Add missing parens around assignment that is compared to zero.
2) Make some variables that only take non-negative values unsigned.
3) Some casts/type changes to fix other constness warnings.
4) Make one variable a const char *.
5) Make sure termwidth is positive, it doesn't make sense for it to be negative.
Approved by: dds
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
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 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
subtract one unsigned number from another potentially smaller
one, leading to wraparound (and heap corruption, eventually).
PR: 58813
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
specified, and then the first part of the pattern space is deleted, when
there are two or more input lines, as this results in subtraction of one from
an unsigned integral value of '0'. That bogus value is used in one case
for a loop (that will run far too many times in this case) and a function to
search for a value within a specified range of memory, however now the range
of memory is obscenely large and a segmentation fault will occur. This is
fixed by checking for and appropriately handling a nil pattern space as if
the specified search in memory failed, as indeed it obviously will with nil
pattern space.
Submitted by: Tim J. Robbins <tim@robbins.dropbear.id.au>
PR: bin/34813
Reviewed by: mike
MFC after: 1 day
