| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit f97b6a8f84b3ed209c2aea0958a7b889d0bf27ed, as it
turns out our fuzz implementation is just too naive. We can have more
leading context than trailing context and vice-versa, so we can't really
assume they're the same.
Restore the previous bug and we can work on it post-branch.
Reported by: cy
|
|
The older GNU patch that we had in base did not properly handle spaces
in filenames in unified diffs, but bsdpatch seems to have handled this
fine at least since the version we imported into base initially. Add a
test with spaces in the filename specifically to be sure.
PR: 181272
|
|
When the first line of a file is a removal, we may not have any leading
context. Only adjusting p_context if context > 0 means that we
incorrectly believe that we have 100 lines of context when the reality
is that we have none.
This fixes a bug with fuzz-checking, which ends up fuzzing away the line
we're trying to replace if it's the first line in the file. We use
pch_context() to determine a reasonable max-fuzz.
PR: 250511
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D51837
|
|
After building packages we have a number of new
and updated Makefile.depend files
Reviewed by: stevek
|
|
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix
|
|
This replaces fgetln() with getline(). The main reason for this is
portability, making things easier for people who want to compile these
tools on non-FreeBSD systems.
I appreciate that's probably not the top concern for FreeBSD base tools,
but fgetln() is impossible to port to most platforms, as concurrent
access is essentially impossible to implement fully correct without the
line buffer on the FILE struct. Other than this, many generic FreeBSD
tools compile fairly cleanly on Linux with a few small changes.
Most uses of fgetln() pre-date getline() support (added in 2009 with
69099ba2ec8b), and there's been some previous patches (ee3ca711a898
8c98e6b1a7f3 1a2a4fc8ce1b) for other tools.
Obtained from: https://github.com/dcantrell/bsdutils and
https://github.com/chimera-linux/chimerautils
Signed-off-by: Martin Tournoij <martin@arp242.net>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/893
|
|
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D43850
|
|
if `first_guess' is zero then main() assumes that locate_hunk has failed
and aborts the patch operation. Instead, make sure to return 1 (the
line number) so that the patch operation can continue.
Issue originally found by Neels Hofmeyr in the regress suite of the diff
implementation for got, where the tests assume that applying a diff with
`patch' and then again with `patch -R' yields back the original file.
Obtained from: OpenBSD (CVS patch.c,v 1.71)
|
|
Remove /^\.\\"\s*\$FreeBSD\$$\n/
|
|
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
|
Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/
|
|
Found by fuzzing (afl) in OpenBSD.
Obtained from: OpenBSD (CVS 1.65)
|
|
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
|
|
|
|
When a file is missing, patch(1) will prompt for a filename to try and
patch it. If we're doing a dry-run, we'll output that the patch to the
source file was either ignored/failed. If you ignore the prompt in a
dry-run (i.e. just hit enter), we'll output:
X out of X hunks ignored while patching (null)
Let's improve the aesthetics a bit and just omit the last part if the
prompt was ignored:
X out of X hunks ignored
Unfortunately we can't really test this without expect(1) because both
force and batch mode will use the first best guess, which is wiped out
by the "File to patch:" prompt. We could record the initially derived
bestguess there and use *that*, but given that this is only possible in
an interactive session I think it's fine to just omit the filename
rather than adding a fair amount of complexity (which could also break
other scenarios I haven't considered yet)..
Reviewed by: des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38179
|
|
musl libc fgetln is a bit more pickier.
Hinted by: chimera-linux (git 31491e1de2e1241885984cd9e4b978965f14eda4)
|
|
MFC after: 2 weeks
|
|
- no blank before trailing delimiter
MFC after: 1 week
Notes:
svn path=/head/; revision=368807
|
|
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
Notes:
svn path=/head/; revision=364291
|
|
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
Notes:
svn path=/head/; revision=354328
|
|
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.
Notes:
svn path=/head/; revision=351866
|
|
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)
Notes:
svn path=/head/; revision=351836
|
|
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
Notes:
svn path=/head/; revision=344677
|
|
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
Notes:
svn path=/head/; revision=327826
|
|
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)
Notes:
svn path=/head/; revision=327064
|
|
Obtained from: OpenBSD (CVS 1.64)
Notes:
svn path=/head/; revision=327063
|
|
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
Notes:
svn path=/head/; revision=326084
|
|
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.
Notes:
svn path=/head/; revision=326025
|
|
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)
Notes:
svn path=/head/; revision=325564
|
|
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
Notes:
svn path=/head/; revision=325365
|
|
Sponsored by: Dell EMC Isilon
Notes:
svn path=/head/; revision=325188
|
|
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
Notes:
svn path=/head/; revision=324431
|
|
Sometimes patches coming from other places have extra a/ and b/
directories prepended to filenames.
Obtained from: OpenBSD (CVS rev. 1.57, 1.58)
Notes:
svn path=/head/; revision=320579
|
|
This can happen if no tty is available.
Obtained from: OpenBSD (CVS rev 1.54)
MFC after: 5 days
Notes:
svn path=/head/; revision=319676
|
|
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
Notes:
svn path=/head/; revision=314704
|
|
Small style fix with here.
Pointed out by: kib
Notes:
svn path=/head/; revision=311110
|
|
patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX.
This doesn't really work for 32 bit platforms.
Pointed out by: kib
Notes:
svn path=/head/; revision=311109
|
|
We can handle such "big data" without much trouble.
Try to do a better job at detecting the rejection cause while here.
MFC after: 2 weeks
Notes:
svn path=/head/; revision=311106
|
|
Similar to r306560, plus remove an unused macro.
Suggested by: jmallett
Notes:
svn path=/head/; revision=306561
|
|
Minor cleanup inspired by a new patch(1) variant in schily tools.
For reference:
https://sourceforge.net/p/schillix-on/
MFC after: 1 week
Notes:
svn path=/head/; revision=306560
|
|
Independent of the maximum length, the return type for strnlen(3)
is always size_t.
Notes:
svn path=/head/; revision=298531
|
|
Integer i is used to index p_end of type LINENUM (actually long).
Match the types.
MFC after: 5 days
Notes:
svn path=/head/; revision=298530
|
|
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
Notes:
svn path=/head/; revision=291563
|
|
arc lint is helpful
Reviewed By: allanjude, wblock, #manpages, chris@bsdjunk.com
Differential Revision: https://reviews.freebsd.org/D3337
Notes:
svn path=/head/; revision=289677
|
|
Obtained from: DragonFly via OpenBSD
Relnotes: yes
MFC: never
Notes:
svn path=/head/; revision=286795
|
|
Suggested by: ed
MFC after: 2 weeks
Notes:
svn path=/head/; revision=286617
|
|
by jmg@.
Reviewed By: pfg
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D3353
Notes:
svn path=/head/; revision=286601
|
|
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]
Notes:
svn path=/head/; revision=286346
|
|
support by replacing system() with execve().
Future revisions may remove the functionality completely.
Obtained from: Bitrig
Security: CVE-2015-1416
Notes:
svn path=/head/; revision=285974
|
|
Differential Revision: https://reviews.freebsd.org/D3146
Reviewed by: pfg
Approved by: markj (mentor)
MFC after: 1 week
Relnotes: yes
Sponsored by: EMC / Isilon Storage Division
Notes:
svn path=/head/; revision=285772
|
