From owner-svn-src-all@freebsd.org Sun Aug 16 23:55:24 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2B81A379AE9; Sun, 16 Aug 2020 23:55:24 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BVDZN0Lxbz3yMq; Sun, 16 Aug 2020 23:55:24 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E4BFA18386; Sun, 16 Aug 2020 23:55:23 +0000 (UTC) (envelope-from imp@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 07GNtNph080498; Sun, 16 Aug 2020 23:55:23 GMT (envelope-from imp@FreeBSD.org) Received: (from imp@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 07GNtNbV080497; Sun, 16 Aug 2020 23:55:23 GMT (envelope-from imp@FreeBSD.org) Message-Id: <202008162355.07GNtNbV080497@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: imp set sender to imp@FreeBSD.org using -f From: Warner Losh Date: Sun, 16 Aug 2020 23:55:23 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r364291 - head/usr.bin/patch X-SVN-Group: head X-SVN-Commit-Author: imp X-SVN-Commit-Paths: head/usr.bin/patch X-SVN-Commit-Revision: 364291 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 23:55:24 -0000 Author: imp Date: Sun Aug 16 23:55:23 2020 New Revision: 364291 URL: https://svnweb.freebsd.org/changeset/base/364291 Log: Remove heuristic for dealing with trailing newlines being truncated by mailers. 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 Modified: head/usr.bin/patch/pch.c Modified: head/usr.bin/patch/pch.c ============================================================================== --- head/usr.bin/patch/pch.c Sun Aug 16 22:50:59 2020 (r364290) +++ head/usr.bin/patch/pch.c Sun Aug 16 23:55:23 2020 (r364291) @@ -587,16 +587,11 @@ another_hunk(void) len = pgets(true); p_input_line++; if (len == 0) { - if (p_max - p_end < 4) { - /* assume blank lines got chopped */ - strlcpy(buf, " \n", buf_size); - } else { - if (repl_beginning && repl_could_be_missing) { - repl_missing = true; - goto hunk_done; - } - fatal("unexpected end of file in patch\n"); + if (repl_beginning && repl_could_be_missing) { + repl_missing = true; + goto hunk_done; } + fatal("unexpected end of file in patch\n"); } p_end++; if (p_end >= hunkmax)