Add a New Comment (Rich Markup)
Comment Type & Canned Response: None No canned response available
( Jump to the original submission )
Hmm, interesting. Thanks for tracking this down.
In the early days, changes were tracked in rcs (see the rcs-history branch in git). Individual changes weren't isolated very well. The commit message pertaining to this change doesn't seem very helpful:
> (another_hunk): Keep context as LINENUM, not int. If the replacement is missing, calculate > its context correctly. Don't assume input ends in newline. Keep track of patch prefix > context separately from suffix context; this fixes several bugs. Don't assume blank lines > got chopped if the replacement is missing. Report poorly-formed hunks instead of aborting. > Do not use strcpy on overlapping strings; it's not portable. Work even if lines are > incomplete. Fix bugs associated with context-less context hunks, particularly when patching > in reverse.
The coding style you're proposing looks fine and seems consistent with the rest of the code, so I'm fine with that.
As to what that check in patch-2.1 was for, the pattern and replacement sections of a hunk usually indicate the offset (line number) and the length of the section. When the length is omitted, it is assumed to be 1. I think the check is meant to detect when the length was assumed to be 1 and it then turns out that that guess was wrong. (Some more thinking needed.)
Since I wanted the test cases to pass when building patch-2.7.6, I downloaded and built patch-2.1, which doesn't have this bug, and triaged the diffs against v2.7.6 for the function another_hunk(), which incorrectly reports the mangled hunk both in the reporter's test case and in the context-format test included in the package.
I found that the problem was fixed by adapting lines 702-707 from pch.c v2.1, which don't have an equivalent, apart from the comment, in v2.7.6:
/* redundant 'new' context lines were omitted - set */ /* up to fill them in from the old file context */ if (!p_context && p_repl_lines == 1) { p_repl_lines = 0; p_max--; }
Although it would be stretching the truth to say that I really came to understand how this 600-line function (now 25% bigger) works, the equivalent of line 703 appears to be
if (!p_prefix_context && !p_suffix_context && p_repl_lines == 1) {
Personally, I'd like to see arithmetic tests coded explicitly
if (p_prefix_context != 0 && p_suffix_context != 0 && p_repl_lines == 1) {
but I created a patch in line with the style used in the existing code.
[Personally, I'd like the code to have a specification, to be properly commented when, as in this package, C is being used like an assembly language, to match the data being processed, and so on, but hey, if it was good enough for Perl ...]
With pch.c updated by this patch (and the context-format test removed from the XFAIL list), all the PASS test cases pass.
(file #48104)
It seems that you missunderstand my comment.
The gpatch sources have been modified too much and I also modified Larry's patch sources. It seems to be hard to compare my POSIX patch and gpatch to find the cause.
I recommend you to go back to patch-2.0-PL12u10 to find out when/how gpatch introduced the bug. You could use the revision control to get older versions than 2.5...
So you're telling me, in the GNU patch bug tracker, that other implementations of the patch algorithm don't have this bug which GNU patch has since its earliest archived version (2.5). Fair enough, send a fix.
You are mistaken, the problem does not exist in the original patch sources and it does not exist in the POSIX patch that I created from the original sources, see:
https://sourceforge.net/projects/schilytools/files/
I realized the gpatch problem two days ago when running a regression test against my POSIX patch and using gpatch as a reference for comparing the patched results.
Interesting -- this bug seems to exist in all versions of patch.
This occur in 2.6.1 (Ubuntu) and 2.7.1 (Cygwin).
$ echo -ne "a\nb\n" > 1.txt $ echo -ne "a\n" > 2.txt $ diff -C0 1.txt 2.txt > 12.patch $ patch 1.txt 12.patch patch: **** replacement text or line numbers mangled in hunk at line 4 $ patch -R 2.txt 12.patch patch: **** replacement text or line numbers mangled in hunk at line 4
This doesn't occur if the order of the input is exchanged.
$ echo -ne "a\nb\n" > 1.txt $ echo -ne "a\n" > 2.txt $ diff -C0 2.txt 1.txt > 21.patch $ patch 2.txt 21.patch patching file 2.txt $ patch -R 1.txt 21.patch patching file 1.txt
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.10