1 files changed, 61 insertions, 0 deletions
diff --git a/results/classifier/118/none/1655700 b/results/classifier/118/none/1655700
new file mode 100644
index 00000000..80496678
--- /dev/null
+++ b/results/classifier/118/none/1655700
@@ -0,0 +1,61 @@
+graphic: 0.726
+mistranslation: 0.575
+device: 0.571
+performance: 0.569
+vnc: 0.537
+ppc: 0.501
+risc-v: 0.438
+PID: 0.416
+socket: 0.411
+files: 0.403
+VMM: 0.396
+i386: 0.383
+x86: 0.379
+network: 0.378
+arm: 0.353
+kernel: 0.337
+virtual: 0.315
+semantic: 0.311
+KVM: 0.286
+TCG: 0.276
+register: 0.258
+architecture: 0.227
+hypervisor: 0.221
+user-level: 0.208
+permissions: 0.208
+boot: 0.188
+assembly: 0.175
+debug: 0.174
+peripherals: 0.155
+
+disas/libvixl/vixl/invalset.h: possible dodgy code in binary search ?
+
+
+[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check.
+
+Source code is
+
+    while (!IsValid(elements[low]) && (low < high)) ++low;
+
+Also:
+
+qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check.
+
+The source code is
+
+   while (!IsValid(elements[high]) && (low < high)) --high;
+
+Mind you, these lines of code look similar but didn't get reported:
+
+    while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle;
+    while (!IsValid(elements[middle]) && (low + 1 < middle)) --middle;
+
+Given that binary search is notoriously tricky to get correct and a standard C library routine
+I am puzzled as to why the standard library routine didn't get used, with of course a custom
+comparison function.
+
+That doesn't look like a bounds check to me, so I think your checker is producing false positives.
+
+libvixl is third-party code in any case, so stylistic questions are better directed to them upstream. But I think the difference between this code and a standard binary search is (as the comment says) that it ignores invalid elements in the array.
+
+