[Toybox] patch and fuzz

[Rob Landley]

On 6/26/20 2:35 PM, enh via Toybox wrote:
> toybox patch fails to apply the patch
> https://android.googlesource.com/platform/external/snakeyaml/+/refs/heads/master/src/patches/android/Representer.patch

That's html, I clicked the ".txt" link at the bottom and it downloaded a block
of "Zy95YW1sL3NuYWtleWFtbC9yZXByZXNlbnRlci9SZXByZXNlbnRlci5qYXZhCkBAIC0xNSw3"
which I don't recognize the encoding of?

  $ file Representer.txt
  Representer.txt: ASCII text, with very long lines, with no line terminators

The debian file command is editorializing, but not helpful.

> to the file https://android.googlesource.com/platform/external/snakeyaml/+/refs/heads/master/src/main/java/org/yaml/snakeyaml/representer/Representer.java.

Could you send me the two files?

> the worst part is that it _thinks_ it succeeds :-(
> 
> the interesting bit happens when we come to apply this hunk:
> 
> @@ -15,7 +15,6 @@
> */
>  package org.yaml.snakeyaml.representer;
> 
> -import java.beans.IntrospectionException;
>  import java.util.ArrayList;
>  import java.util.Arrays;
>  import java.util.Iterator;
> 
> here:
> 
> package org.yaml.snakeyaml.representer;
> 
> import java.beans.IntrospectionException;
> import java.util.ArrayList;
> import java.util.Arrays;
> import java.util.Collections;
> import java.util.Iterator;
> import java.util.List;
> 
> the eagle-eyed human will notice that there's an extra "Collections"
> in the actual file that isn't in the patch, because the patch was
> actually against an older version of the source.

Didn't commit 333a10f9ef59 fix this back in February? (It was supposed to...)

> the bug is that toybox drops that new line in its output.
> 
> it reads it:
> 
> MAYBE:
> IN: import java.beans.IntrospectionException;
> MAYBE: -import java.beans.IntrospectionException;
> IN: import java.util.ArrayList;
> MAYBE:  import java.util.ArrayList;
> IN: import java.util.Arrays;
> MAYBE:  import java.util.Arrays;
> IN: import java.util.Collections;
> FUZZED: 21  import java.util.Iterator;
> 
> but then it does a `goto fuzzed` and explicitly drops that line it
> just read. which is clearly wrong here, but the code comment
> explicitly calls out this behavior:
> 
>     // If match failed, flush first line of buffered data and
>     // recheck buffered data for a new match until we find one or run
>     // out of buffer.

That's leading data. The idea was if you're matching

@@
  abc
- def
  ghi

And the data says:

 abc
 abc
 def
 ghi

It shouldn't see the first abc, read in the second abc and go "nope, that's not
def" and then discard _both_ before checking again. (It has to advance _one_
line and try again, thus checking at every possible offset, including rechecking
the data it's already buffered  because it thought it might be a later part of
the hunk under consideration. The actual _start_ of the hunk might be in that
mismatched later part it's already read in.)

> so i'm not quite sure i understand the intended logic here. when would
> you ever want to drop an input line that doesn't have a '-' or '+'
> line in the hunk?

Can you send me the test files? (I can try to put together a test from what
you've sent me, but I'd rather have the real one.)

Thanks,

Rob