[Toybox] patch and fuzz
Rob Landley
rob at landley.net
Sun Jun 28 23:29:04 PDT 2020
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
More information about the Toybox
mailing list