src/usr.bin/patch/patch.c, branch releng/12.4 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.4 2019-12-03T18:55:09Z MFC r351836, r351866, r354328: patch(1) /dev/null testing+improvement 2019-12-03T18:55:09Z Kyle Evans kevans@FreeBSD.org 2019-12-03T18:55:09Z urn:sha1:be3a0c5043ce6f6dd57ad55276e9b67447be6867 r351836: patch(1): add some basic tests 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) r351866: patch(1): fix the file removal test, strengthen it a bit 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. r354328: patch(1): give /dev/null patches special treatment 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 r344677: patch(1): Exit successfully if we're fed a 0-length patch 2019-04-04T17:21:30Z Kyle Evans kevans@FreeBSD.org 2019-04-04T17:21:30Z urn:sha1:ca2dafdd851c002b7bf2b1e2dadd7ee432712caa 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. patch: rejname[] is also -r option buffer, and should be PATH_MAX. 2017-12-21T16:19:10Z Pedro F. Giffuni pfg@FreeBSD.org 2017-12-21T16:19:10Z urn:sha1:c844f14e37e57b9f259fb60423456b297b3951e1 Obtained from: OpenBSD (CVS 1.64) patch(1): don't assume a match if we run out of context to check 2017-11-22T03:44:19Z Kyle Evans kevans@FreeBSD.org 2017-11-22T03:44:19Z urn:sha1:bc4f0fe3588183058f52c53f9cf59b77e19842db 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 Revert r325365 2017-11-08T23:11:15Z Kyle Evans kevans@FreeBSD.org 2017-11-08T23:11:15Z urn:sha1:752e881db7398b10410d26c7d69176ec998d9c3b 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) patch(1): don't assume a match if we run out of context to check 2017-11-03T17:04:30Z Kyle Evans kevans@FreeBSD.org 2017-11-03T17:04:30Z urn:sha1:ed3b30599370432f6ac501e36099f597f5999d27 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 patch(1): replace strnlen() with a simpler strlen(). 2017-01-02T18:27:35Z Pedro F. Giffuni pfg@FreeBSD.org 2017-01-02T18:27:35Z urn:sha1:fa812237434edee9745e7cf6e9ef4481cf2b5a8c Small style fix with here. Pointed out by: kib Revert r311106: 2017-01-02T18:23:31Z Pedro F. Giffuni pfg@FreeBSD.org 2017-01-02T18:23:31Z urn:sha1:4f548c1916e86995b61b678743c91d689bba8581 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 patch(1): extend the maximum length of a line from USHRT_MAX to UINT_MAX. 2017-01-02T17:12:14Z Pedro F. Giffuni pfg@FreeBSD.org 2017-01-02T17:12:14Z urn:sha1:ad8469feec8a84469d38b4a1237fd39abea16198 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 Adjust a type from r267490. 2016-04-24T04:28:04Z Pedro F. Giffuni pfg@FreeBSD.org 2016-04-24T04:28:04Z urn:sha1:3548708c4713b248a839f3ef8928dba5c9642a91 Independent of the maximum length, the return type for strnlen(3) is always size_t.