forked from enlightenment/efl
now here's the rub. from the glibc manual page: ... int memcmp(const void *s1, const void *s2, size_t n); DESCRIPTION The memcmp() function compares the first n bytes (each interpreted as unsigned char) of the memory areas s1 and s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or be greater than s2. RETURN VALUE The memcmp() function returns an integer less than, equal to, or greater than zero if the first n bytes of s1 is found, respectively, to be less than, to match, or be greater than the first n bytes of s2. ... this explicitly says that s1 and s2 have their BYTES compared... and then returns just some value < 0, 0 or > 0 based on the difference. what that value is and means is not defined, as long as it is < 0, 0 or > 0. so the C standard has this to say: 6.3.1.3 Signed and unsigned integers 2. Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type. so a result of -255 (possible) is converted by REPEATEDLY adding the max size of the new type (255) until within range... so ... -255 + 255 = 0 ... within range.. BUT FALSE! so why do we see this now? something changed in memcpy behavior. before we ONLY saw values of -1, 0 or 1 - nothing else, NOW we see thins like: -12288 49152 4096 16384 61440 -53248 so memcpy changed behavior, though within specs of the manual page anyway, but now the values can be ones that break the simple assignment. SVN revision: 75159 |
||
---|---|---|
legacy |