* Thomas de Bock via Gcc: > Sorry for my wording, that is not the only thing memcmp gives us, but it > does not give us information regarding which fields mismatched. So we cannot > deal with (after !='s are converted to =='s) blocks where not all blocks in > a chain have the same node as their (eventual, possibly through fallthru's) > FALSE edge's destination, is what I was trying to say.
We could add a __memmismatch function to glibc, which returns the address of the first non-matching byte (or something to that effect, offset might be better if you want to align it down to the start of a field). This is one of the primitives provided by Java APIs covering this area. The question is how useful this is in general for tuple comparison if you do not have a fixed field width. On the other hand, we already added __memcmpeq for use by GCC recently, and it's still unused. 8-/ Thanks, Florian
