LLVM Compiler 2.0 bug?

When the following code is compiled with LLVM Compiler, it doesn't operate correctly. (i doesn't increase.) It operates correctly when compiling with GCC 4.2. Is this a bug of LLVM Compiler?

#include <stdio.h>
#include <string.h>

void BytesFromHexString(unsigned char *data, const char *string) {
    printf("bytes:%s:", string);
    int len = (int)strlen(string);
    for (int i=0; i<len; i+=2) {
        unsigned char x;
        sscanf((char *)(string + i), "%02x", &x);
        printf("%02x", x);
        data[i] = x;
    }
    printf("\n");
}

int main (int argc, const char * argv[])
{
    // insert code here...
    unsigned char data[64];
    BytesFromHexString(data, "4d4f5cb093fc2d3d6b4120658c2d08b51b3846a39b51b663e7284478570bcef9");
    return开发者_如何学编程 0;
}

For sscanf you'd use %2x instead of %02x. Furthermore, %2x indicates that an extra int* argument will be passed. But you're passing an unsigned char*. And finally, sscanf takes a const char* as first argument, so there's no need for that cast.

So give this a try :

int x;
sscanf((string + i), "%2x", &x);

EDIT : to clarify why this change resolves the issue : in your code, sscanf tried to write sizeof(int) bytes in a memory location (&x) that could only hold sizeof(unsigned char) bytes (ie. 1 byte). So, you were overwriting a certain amount of memory. This overwritten memory could very well have been (part of) the i variable.

From the compiler side of things the reason for this code behaving differently is that gcc and llvm (or any other compiler) may lay out the stack differently. You were likely just clobbering something else on the stack before that you didn't need for this example, but with the different layout for the llvm compiler you were clobbering something more useful.

This is another good reason to use stack protectors when debugging a problem (-fstack-protector-all/-fstack-protector). It can help flush out these issues.