bug of the day: a memcmp that only compares every fourth byte
Watch out for missed warnings on vendor C++ toolchains - Graham Sutherland's Blog

@gsuberland unrelated but shouldn't it be something like *(a++) ^ *(b++)?
@mildsunrise probably yeah I'm tired lol
@mildsunrise wait no, cos (a++) would be equivalent to pre-increment
@mildsunrise but yeah it should be *a ^ *b and then separately incrementing
@gsuberland (a++) is post increment, pre increment would be (++a)
@mildsunrise if you wrap it in brackets and deref outside doesn't it turn into pre behaviour regardless? (now I'm writing this I'm realising it probably doesn't, but this is c++ so principle of most surprise applies lol)
@gsuberland "Rest assured, our embedded library is heavily optimised to use efficient word-sized operations."

@gsuberland i'm reminded of a weird bug i found in a compiler. in this case the vendor (green hills c compiler for coldfire cpus) converted a sequence like this:

uint8_t idx;
idx = <user input, a single character>;
char newbyte = lookup_table[idx];

The code was converting upper/lowercase letters iirc.

In this case the compiler actually converted idx to a signed value using a coldfire MVS.B instruction for some reason, so you could obtain values outside of the lookup table array if the user input a byte >= 0x80.

Not incredibly useful on its own in the app I was analyzing, but the bug was in the compiler itself so needed to be fixed...I never would have spotted the bug were it not for using Ida back in the day.

@gsuberland is it doing what i think it's doing?
@dysfun it's a constant time implementation if that helps

@dysfun essentially this:

int memcmp32(uint32_t* a, uint32_t* b, int words)
{
uint8_t sum = 0; // whoops
while(words--) {
sum |= *a++ ^ *b++;
}
return sum;
}

@gsuberland yes, that's exactly what i thought

@dysfun ehehehe

the code in question lucked out by never actually using it in a path that matters, but it's in a core lib for something security sensitive so easily could've ended up being bad

@gsuberland yeah it lucked out by not having bit rotted yet

@dysfun @gsuberland

Hmm… is the issue casting 64-bit memory to an 8-bit char?

@gsuberland what about an strncmp that doesn't stop at a null terminator
@gsuberland ....the famous wii trucha bug is probably because broadon didn't understand the difference between strncmp and memcmp, in their own libc they do the same thing
@gsuberland my bad. I misheard directions, and used AL when what the boss really wanted was AI.
@gsuberland
It's not named allmemcmp for a reason.