Thank you all On Sun, Jan 3, 2016 at 7:51 PM, Martin Sebor <msebor@xxxxxxxxx> wrote: > On 01/02/2016 06:26 AM, Vincent Diepeveen wrote: >> >> >> Assuming function f() has been defined >> Comparing 2 different types is undefined in C. >> >> Note that compilers that optimize better than GCC, say intel c++ which >> is 10% - 30% faster for many of my codes, statistical odds it goes wrong >> is higher than GCC. >> >> In assembler it could for example XOR just register ah, which is a 8 >> bits register and then further you compare register aex with another >> value. > > > This description and the mention of Intel C++ reminds of > a coding bug we would occasionally run into with the bi-endian > ICC. The bug was caused by inconsistent function declarations > (e.g., by accidentally redeclaring a function defined to return > a big-endian bool in a little-endian region, effectively lying > to the compiler about the endianity of the return type). Even > when the function returned true, the caller would read it as > false. This was because the return value was stored by > the called function in the high (big-endian) byte and extracted > by the caller from the low (little-endian) byte of the register. > The same problem can happen even without mixing big- and little > endian code, but the bi-endian ICC makes it easier and tricky > to debug. In both cases, the behavior of such programs is > undefined, but it has nothing to do with comparing values of > different types and everything with the mismatched function > declarations. > > Martin
