Avoiding strict aliasing violation in hash function

Question

How I can avoid strict aliasing rule violation, trying to modify char* result of sha256 function.

Compute hash value:

std::string sha = sha256("some text");
const char* sha_result = sha.c_str();
unsigned long* mod_args = reinterpret_cast<unsigned long*>(sha_result);

than getting 2 pieces of 64 bit:

unsigned long a = mod_args[1] ^ mod_args[3] ^ mod_args[5] ^ mod_args[7];
unsigned long b = mod_args[0] ^ mod_args[2] ^ mod_args[4] ^ mod_args[6];

than getting result by concat that two pieces:

unsigned long long result = (((unsigned long long)a) << 32) | b;

I really hopu the actual string you compute the hash for is longer than what you show, or you will be indexing out of bounds when calculating `a` and `b`. — Some programmer dude, Jan 12 '16 at 16:19
@Joachim Pileborg: sha256 must always return 32 bytes of hash. — Mykola, Jan 12 '16 at 16:22
See http://stackoverflow.com/questions/12612488/aliasing-t-with-char-is-allowed-is-it-also-allowed-the-other-way-around — Mark Ransom, Jan 12 '16 at 16:24
That still doesn't mean you can go out of bounds of the input data, you need to pad it. — Some programmer dude, Jan 12 '16 at 17:00
You have bigger problems than strict aliasing violation. How did you get that `char* sha_result = sha.c_str()` to compile? — Lightness Races in Orbit, Jan 15 '16 at 17:07
@Mykola: It shouldn't. `sha.c_str()` is a `const char*`. Note the `const`. — Lightness Races in Orbit, Jan 15 '16 at 17:37

score 7 · Accepted Answer · edited Jan 15 '16 at 16:40

As depressing as it might sound, the only true portable, standard-conforming and efficient way of doing so is through memcpy(). Using reinterpret_cast is a violation of strict aliasing rule, and using union (as often suggested) triggers undefined behaviour when you read from the member you didn't write to.

However, since most compilers will optimize away memcpy() calls, this is not as depressing as it sounds.

For example, following code with two memcpy()s:

char* foo() {
  char* sha = sha256("some text");
  unsigned int mod_args[8];
  memcpy(mod_args, sha, sizeof(mod_args));
  mod_args[5] = 0;
  memcpy(sha, mod_args, sizeof(mod_args));
  return sha;
}

Produce following optimized assembly:

foo():                                # @foo()
        pushq   %rax
        movl    $.L.str, %edi
        callq   sha256(char const*)
        movl    $0, 20(%rax)
        popq    %rdx
        retq

It is easy to see, no memcpy() is there - the value is modified 'in place'.

Does anything in the C++ Standard indicate that it doesn't inherit C99's awful rules about `memcpy`? — supercat, Sep 02 '16 at 21:07

Avoiding strict aliasing violation in hash function

1 Answers1