2017-09-05 17:28 GMT+02:00 Andreas Grünbacher <agr...@gnu.org>: > 2017-09-04 20:37 GMT+02:00 Benno Schulenberg <bensb...@telfort.nl>: >> >> Op 4-09-2017 om 18:37 schreef Andreas Grünbacher: >>> >>> 2017-09-04 18:04 GMT+02:00 Benno Schulenberg <bensb...@telfort.nl>: >>>> >>>> The original testor.c has this: >>>> $ wc testor.c >>>> 95 388 2719 testor.c >>> >>> >>> Not in my testing: >>> >>> $ wc testor.c >>> 103 415 2983 testor.c >> >> >> Ouch. Attached a wrong testor.c? I could have sworn I attached >> the correct, unpatched file. :| Now then. > > I could reproduce now. It seems that locate_hunk starts scanning the > input file too high up after applying the first hunk, and so it > "finds" the same position again. I guess last_frozen_line is set > wrong, but I haven't finished debugging the code yet.
I've pushed a fix to the repository on Savannah. Patch will now handle this case more reasonably: $ patch testor.c < goes-wrong.patch patching file testor.c Hunk #1 succeeded at 44 (offset 37 lines). Hunk #2 FAILED at 48. 1 out of 2 hunks FAILED -- saving rejects to file testor.c.out.rej The test suite still passes, and I can't think of any legitimate patches that this fix would now cause to fail. Let's hope I didn't overlook anything. Thanks, Andreas
