Closed EliaGeretto closed 5 years ago
My doubt on the expected behavior stems from the fact that using the infer_shape
function to merge those four bytes together, the resulting tree would be the following:
[0,0)
/
[0,2)
/ \
... [2,3)
\
[3,4)
\
[4,5)
\
[2,6)
As you can see, the node that gets modified is the one at the bottom and not the one at the top.
Thanks for your feedback, EliaGeretto. It is not intended behaviors. I have merged it to dev branch and will merge to master soon.
Thank you for your clarification! However, there is still a question that you did not answered. Is the difference between shape inference for math operators and load
s intended? The difference between the second and the third tree I posted here. In the first, the aggregation node is at the beginning of the sequence, in the second one, it is at the end.
If you want to make the behavior uniform, I can create another pull request. It's a single line change within the same function.
You are right. They had better should be consistent. I fix this issue, and add tests in https://github.com/AngoraFuzzer/Angora/commit/66582b35f655d17f9df678cc99e929123299b6b1 .
Pleasse check it. Thanks.
Supposing to have a label
lb
, corresponding to the bit vector001111
, the path describing it on the tree could be as follows, withlb
pointing to the node that contains[5,6)
.Calling
infer_shape2(lb, 4)
, the function should be able to group bytes from 2 to 5 together. This, however, with the current implementation, does not happen. After some debugging, it appears that thefor
loop is moving thecur_lb
one too many times and make it point to the root, instead of[2, 3)
, when terminating the loop. This patch fixes that behavior and correctly groups the bytes, producing the following tree after the execution:If this is not the intended behavior, please let me know.