Comment by sqrt17 | Hacker News Reader

Comment by sqrt17 | Hacker News Reader

There are really two valid uses for aliasing/type-punning: one is bit twiddling (e.g. you have a data structure where you want to access specific bits or bytes, e.g. the exponent of floats, or having a mixed stream of floats/characters/shorts), and the other one is type-punning as poor man's polymorphy, as in different sockaddr structures in the C library or the representation of event types in Xlib.

It's easy to claim that these uses don't exist, but they do occur in every larger piece of C software (especially when that large piece of software has performance-critical parts, which is increasingly the main use of C). And in both cases, the compiler breaks cases where the aliasing is introduced in the current function, and also exploited there; this should be reasonably easy to detect (compared to the general aliasing problem, which is unsolvable).

It seems to me that it should be possible to use memcpy between multiple C variables to avoid straight type-punning, and then have the compiler reöptimize it into aliased memory or registers (assuming the source isn't volatile memory or something like that, in which case things get trickier anyway). This is roughly what I do in my C programs these days.

In some cases, declaring alignment may be hard to do portably; it's probably possible to use union tricks to force there to exist a dummy statement that implies certain alignment without breaking the aliasing rules, but I don't know for sure since I haven't run into such cases in practice yet.

As a nonrepresentative example, the simple function:

  uint64_t foo(char x[8]) {
    uint64_t y; memcpy(&y, &x[0], 8); return y;
  }

gets compiled into a single « movq (%rdi), %rax » by gcc -S -O2 on my AMD64 machine with GCC 4.6.1.

Polymorphism as with sockaddr and XEvent types is safe. The values are always (in a correct program) read as the same type they were written so there is no type punning.

Reply on news.ycombinator.com