Question

What is the difference between

*(unsigned*)d = *(unsigned*)s; 
d+=4; s+=4; 
*(unsigned*)d = *(unsigned*)s; 
d+=4; s+=4;

and

*(unsigned long*)d = *(unsigned long*)s;
d+=8; s+=8;

on 64bit systems?

Answer 1

Provided that nothing unpleasant happens in respect of padding bits or strict aliasing rules, and assuming the sizes of the types are as you expect, and provided that the memory regions don’t overlap, and are correctly aligned, then they each copy 8 bytes from one place to another.

Of course, aside from the practical effect there may be a difference in performance and/or code size.

If you’re seeing something break, then look at the actual code emitted, that might tell you what has gone wrong. Unless you have a lot of optimization switched on, and maybe even with optimization, I don’t immediately see why those wouldn’t be equivalent with AMD64, Ubuntu, and gcc.

Things I’ve mentioned that could go wrong:

• padding bits – doesn’t apply to GCC, but the standard permits unsigned an unsigned long to have padding bits, and if so then there could be bit patterns which are trap representations of one or both, which could explode as soon as you dereference.
• strict aliasing – unlikely to affect what that code does, but could affect the code you use to check the result. For example, if s and d are the result of casting pointers-to-double to uint8_t*, and you look at the resulting double, then in one or both cases you might not see the effects of the change because you have an illegal type-pun.
• sizes of the types – shouldn’t apply here since 64 bit linux is LP64, but obviously if sizeof(long) == 4 then the two aren’t equivalent. long is 32 bits on 64bit Windows systems, just not 64bit Linux ones.
• overlap – if d == s + 4, then the two code snippets have different effect. Because of this, you won’t see the first optimized to become the second unless the compiler knows that d and s point to entirely different places (and that’s what C99 restrict is for).
• alignment – I can’t remember what the alignment requirements are for x86-64: for x86 you can get away with an unaligned read/write, it’s just slower. In general, if s or d is correctly aligned for int but not long then there’s a difference. (Edit: apparently you can enable or disable hardware exceptions for unaligned access on x86-64).