Andreas Krey wrote on Tue, Oct 18, 2011 at 10:05:39 +0200:
> On Tue, 18 Oct 2011 08:55:44 +0000, Daniel Shahaf wrote:
> > >
> > > as the diff.
> > >
> > > But happens only with this specific file; can't reproduce with
> > > other content.
> > >
> >
> > Does the file (either before or after the append) contain two identical
> > lines? If so, could you try replacing each line in the file by a unique
> > string? You can do that with
> >
> > % perl -lne 'print $h{$_} ||= $unique++' \
> > <kadr.polon.p >kadr.polon.p.anonymized
>
>
> Nice trick, but unnecessary. The original file was an attachment on the
> mail I replied to.
>
Oops, missed it.
> But that does not trigger the bug:
>
> ===================================================================
> --- kadr.polon.p (revision 1)
> +++ kadr.polon.p (revision 2)
> @@ -450,3 +450,5 @@
> 369
> 370
> 371
371 != 450+3, so there are some duplicate lines.
> +
> +/**/
>
> Replacing each char by another one (individually, not caesar).
> But stays, though no duplicate lines:
>
Huh? This transformation doesn't deduplicate, there were duplicate lines
to begin with, so the result should also contain duplicates.
> Using cat -n on the file: Bug stays, even more surprisingly:
>
> ===================================================================
> --- kadr.polon.p (revision 1)
> +++ kadr.polon.p (revision 2)
> @@ -461,6 +461,8 @@
> 447 EMPTY TEMP-TABLE tt_tytnauk.
> 448 EMPTY TEMP-TABLE tt_stnauk.
> 449 pOstatni = vIlosc.
> + 450 IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> + 451 END.
> 450 IF vIlosc = (pStart + pIlosc - 1) then leave Global_loop.
> 451 END.
> 452 {ws_i/log.i}
>
Interesting.
> So, it is not the line uniqeness, but rather it looks like having to do
> with the line length structure.
>
> I really like to see *that* patch.
>
Which one? The one introducing the bug or fixing it?
> Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds <torvalds@*.org>
> Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2011-10-18 10:23:39 CEST