Hard to say without context. BSIZE is probably a constant and
Ox88 is a LUT and sqNr probably as well (but bounds/types?).
Or maybe a minimum working example?
Can I safely ignore that, or is it something where a malicious compiler now can feel justified to slip in code to format my hard disk?
I very much doubt this is the case Most likely your AV just got a false positive.
Indeed, they are LUT to translate a contiguous range of square numbers (0 to BSIZE-1) to 0x88-style square numbering of a twice-as-wide board. For the patch I was making I also needed to do the reverse lookup.
This doesn't look as undefined behavior in terms of C semantics to me. So it must be a problem in the optimizer, that is might not have preserved the order of the iterations (which could lead to trouble if Ox88[] contained duplicats). I suppose that a compiler is not allowed to slip in malicious code if the undefined behavior is merely a consequence of its own decision to optimize.
BTW, the AV problem was not due to this code. It occurred on a program that opened a socket for listening. But I was testing it under Cygwin (because I was also compiling it there), so the AV did not only delete the .exe, but also many essential Cygwin components (such as the shell).
It probably means that on iteration 45 you'll get an array bound violation, may be the number of elements of Ox88[] is 45?
How large is the constant BSIZE?
Just a guess: maybe some of the types is signed 8-bit type when it should be unsigned?
But that would mean the program wouldn't work at all, hmm. The compiler may be wrong with the warning as well.
Joost Buijs wrote:It probably means that on iteration 45 you'll get an array bound violation, may be the number of elements of Ox88[] is 45?
How large is the constant BSIZE?
Ah, that is what the 45u means!
Yes, you are right, BSIZE is 45. So the <= should have been <, as the square numbering starts at 0. A bit confusing that it doesn't simply say the array bounds are violated, when it apparently sees that they are.
Joost Buijs wrote:Strange AV, I've never had my AV remove anything that it shouldn't, and as a precaution I always have to confirm before it removes something.
Yes you can always change this in the settings.
I used to work for an AV company and the problem is AV tests.
We for instance had bad score due to the fact that a guy pressed "ignore threat" instead of "protect me" button and counted it as a detection miss.
So first we hid the ignore button and later on we added silent automatic removal of stuff that was "confirmed malware" according to remote databases.
It's obvious that one has to do well in various comparative tests. That they're usually conducted by incompetent people is another story.
There are always some false positives so one has to balance between low amount of FPs and high detection ratio. Those two don't always go hand in hand.
Most likely your AV just got a false positive.