src/usr.bin/patch/patch.c, branch release/13.2.0 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F13.2.0 2019-11-04T03:07:01Z patch(1): give /dev/null patches special treatment 2019-11-04T03:07:01Z Kyle Evans kevans@FreeBSD.org 2019-11-04T03:07:01Z urn:sha1:50dacbf6c2a3d32f7e3f20ca98cda23f38817e7f 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 patch(1): Exit successfully if we're fed a 0-length patch 2019-03-01T01:20:21Z Kyle Evans kevans@FreeBSD.org 2019-03-01T01:20:21Z urn:sha1:ef30b5a80910bd877f582248004200065eeb3ef5 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 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.