9 ms·

I wish the myriad articles about this interesting hack would bother to mention that it relies on undefined behaviour. Any time you find yourself doing this:

by rcfox 13y ago

I wish the myriad articles about this interesting hack would bother to mention that it relies on undefined behaviour. Any time you find yourself doing this: *(foo*) you're probably breaking the strict aliasing rule.

deleted 13y ago
[deleted]
- figglesonrails 13y ago
  FWIW, memcpy(&anInt, &aFloat, sizeof(int)) achieves the same thing, is not turned in a real call to memcpy(), and doesn't not break the strict aliasing rule, and does not cause incorrect code to be generated with using `gcc -fstrict-aliasing`.
deletes 13y ago
The behavior is defined, if you disable the rule or your compiler doesn't follow it.
- rcfox 13y ago
  That's the opposite of "defined", in the context of a language discussion.
  - deletes 13y ago
    It is a good thing that actual results rely on the compiler implementation, not the language.
    - rcfox 13y ago
      Sure, your code will work today, with your compiler. But will it work tomorrow? Or what if your client wants to compile it on their machine, in a different operating system, with a compiler that you've never tried?
      - deletes 13y ago
        Readme, documentation, makefile(??)