Every version of patch since the first one posted to mod.sources in 1985 have
included a heuristic for coping with the state of email messaging at the
time. This heuristic would add up to 4 blank lines to a patch if it thought it
needed it. The trouble is, though this causes at least one bug.
The bug in my case is that if you have a context diff whose last hunk only
deletes 3 or fewer lines, then if you try to reverse apply it with -R, it will
fail. The reason for this is the heuristic builds an internal representation
that includes those blank lines. However, it should really replicate the lines
from the pattern lines line it would any other time, not assume they are blank
lines. Removing this heuristic will prevent patch from misapplying the lines
removed after applying a 'fuzz' factor to the previous blank line in the file. I
believe this will only affect 'new-style' 4.3BSD context diffs and not the
older-style 4.2BSD diffs and plain, non-context diffs. It won't affect any of
the newer formats, since they don't use the 'omitted' construct in the same way.
Since this heuristic was put into patch at a time when email / etc ate trailing
white space on a regular basis, and since it's clear that this heuristic is the
wrong thing to do at least some of the time, it's better to remove it
entirely. It's not been needed for maybe 20 years since patch files are not
usually corrupted. If there are a small number of patch files that would benefit
from this corruption fixing, those already-currupt patches can be fixed by the
addition of blank lines. I'd wager that no one will ever come to me with an
example of a once-working patch file that breaks with this change. However, I
have 2 patches from the first 195 patches to 2.11BSD that are affected by this
bug, suggesting that the relative frequency of the issue has changed
signficantly since the original heuristic was put into place.
Reviewed by: phk@
Differential Revision: https://reviews.freebsd.org/D26081
We have a bad habit of duplicating contents of files that are sourced from
/dev/null and applied more than once... take the more sane (in most ways)
GNU route and complain if the file exists and offer reversal options.
This still falls short a little bit as selecting "don't reverse, apply
anyway" will still give you duplicated file contents. There's probably other
issues as well, but awareness is the first step to happiness.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D21535
To remain compatible with GNU patch, we should ensure that once we're
removing empty files after a reversed /dev/null patch we don't remove files
that have been modified. GNU patch leaves these intact and just reverses the
hunk that created the file, effectively implying --remove-empty-files for
reversed /dev/null patches.
Summary:
- basic: test application of patches created by diff -u at the
beginning/middle/end of file, which have differing amounts of context
before and after chunks being added
- limited_ctx: stems from PR 74127 in which a rogue line was getting added
when the patch should have been rejected. Similar behavior was
reproducible with larger contexts near the beginning/end of a file. See
r326084 for details
- file_creation: patch sourced from /dev/null should create the file
- file_nodupe: said patch sourced from /dev/null shouldn't dupe the contents
when re-applied (personal vendetta, WIP, see comment)
- file_removal: this follows from nodupe; the reverse of a patch sourced
from /dev/null is most naturally deleting the file, as is expected based
on GNU patch behavior (WIP)
This change is made in the name of GNU patch compatibility. If GNU patch is
fed a zero-length patch, it will exit successfully with no output. This is
used in at least one port to date (comms/wsjtx), and we break on this usage.
It seems unlikely that anyone relies on patch(1) calling their completely
empty patch garbage and failing, and GNU compatibility is a plus if it helps
with porting, so make the switch.
Reported by: db
MFC after: 2 weeks
Plan A mmap()'s the entire input file and operates on it in memory. The
map(2) call succeeded, so we shouldn't need to bother checking for the NUL
byte as long as we're within our buffer space.
This was clearly intentional to match "the behavior of the original code",
but it creates a discrepancy between Plan A and Plan B that doesn't seem
sensible and it's not inherently wrong to allow a NUL byte.
This change was motivated by the gemspec in net/rubygem-grpc failing to
patch, despite the patch being generated with diff, because a NUL byte was
used as a delimiter in the header briefly in an otherwise text file.
An alternative was considered: to fallback to plan B if plan A won't process
the entire file due to a NUL byte, but I deemed this to be the better option
since plan A isn't failing due to memory limitations and will fail later on
if it's really dealing with a file it shouldn't be.
PR: 224842 (exp-run)
Reported by: swills
Reviewed by: emaste, pfg
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13738
Fix adding and removing files with git-style a/ b/ diffs: only skip
six letters if they actually match "--- a/" and "+++ b/" instead of
laxer checks.
Obtained from: OpenBSD (CVS 1.59)
Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applicable. Matching
with fuzz would be attempted and default to a match when we unexpectedly ran
out of context.
This also affected patches with higher levels of context but had limited
actual context due to the hunk being located near the beginning/end of file.
PR: 74127, 223545 (exp-run)
Reviewed by: emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12631
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.
r325365 caused several ports to fail to patch correctly. Revert it for the
time being until an exp-run can be completed.
Requested by: antoine
Approved by: emaste (implicit)
Patches with very little context (-U0 and -U1) could get misapplied if
the file to be patched changes and a hunk is no longer applicable. Matching
with fuzz would be attempted and default to a match when we unexpectedly ran
out of context.
PR: 74127
Reviewed by: emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12631
Patches like file.txt attached to PR 190195 with a final line formed
like ">(EOL)" could cause a copy past the end of the current line buffer. In the
case of PR 191641, this caused a duplicate line to be copied into the resulting
file.
Instead of running past the end, treat it as if it were a blank line.
PR: 191641
Reviewed by: cem, emaste, pfg
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D12609
reallocarray(3) is a non portable extension from OpenBSD. Given that it is
already in FreeBSD, make easier future merges by adopting in some cases
where the code has some shared heritage with OpenBSD.
Obtained from: OpenBSD
This is not properly respecting WITHOUT or ARCH dependencies in target/.
Doing so requires a massive effort to rework targets/ to do so. A
better approach will be to either include the SUBDIR Makefiles directly
and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose
the benefit of having a userland/lib, userland/libexec, etc, though and
results in a massive package. The current implementation of targets/ is
very unmaintainable.
Currently rescue/rescue and sys/modules are still not connected.
Sponsored by: EMC / Isilon Storage Division
tightening sanity check of the input. [1]
While I'm there also replace ed(1) with red(1) because we do
not need the unrestricted functionality. [2]
Obtained from: Bitrig [1], DragonFly [2]
Security: CVE-2015-1418 [1]
Prevent null pointer dereference on empty input files when diff requires
a specific version.
Fix division by zero for files with long lines (> 1024) in Plan B mode
by supporting arbitrarily long lines.
Obtained from: OpenBSD (CVS Rev 1.41, 1.42)
MFC after: 1 week
Exit with EXIT_FAILURE for invalid arguments.
Fixes NetBSD-PR 43517.
Print version string to stdout instead of stderr;
it is user-requested and not an error.
Obtained from: NetBSD
MFC after: 5 days
The function savestr allows NULL return values during Plan A patching so in
case of out of memory conditions, Plan B can step in. In many cases, NULL
value is not properly handled, so use xstrdup here (it's outside Plan A/B
patching, which means that even Plan B relies on successful operations).
Clean up some whitespaces while here
Obtained from: OpenBSD
MFC after: 2 weeks
Introduce strtolinenum to properly check line numbers while parsing:
no signs, no spaces, just digits, 0 <= x <= LONG_MAX
Properly validate line ranges supplied in diff file to prevent overflows.
Also fixes an out of boundary memory access because the resulting values
are used as array indices.
PR: 195436
Obtained from: OpenBSD (CVS pch.c rev 1.45, 1,46, common.h rev 1.28)
MFC after: 1 week
Check fstat return value. Also, use off_t for file size and offsets.
Avoid iterating over end of string.
Obtained from: OpenBSD (CVS rev. 1.41, 1.43)
MFC after: 1 week
Other implementations of patch(1), including GNU patch and "svn patch"
have a --dry-run option which does the same as our -C or --check
option.
Add a new alias to make our implementation more compatible.
MFC after: 1 week
Patch(1) uses a short int for the line length, which is usually
sufficient for regular diffs, but makes no effort to signal
when there is an overflow.
Change the line length to an unsigned short int to better use
the fact that a length is never negative. The change is loosely
inspired on a related change in DragonFly, but we avoid spending
more memory than necessary.
While here adjust the messages to be clearer on what is happening.
MFC after: 1 week
This change reverts a change from OpenBSD which made use of
calloc, and therefore wasted time initializing arrays that
will later be realloc'ed. Consistently use FreeBSD's
reallocf().
While here also merge the changes from OpenBSD's manpage
patch.1 Rev 1.27:
"patch was moved from user portability (UP) to base in issue 7
and is no longer optional"
MFC after: 1 week
- Ask only once for "Apply anyway". [1]
- Tell user what file have failed patch rather than just how
many hunks failed.
Reported by: jmg via pfg [1]
Tested by: pfg [1]
Approved by: re (gjb)
