[comex]

> So, for example, you know if at offset 0xDEADBEEF there is are 8 bytes which are holding a number that you want to use, you can access that chunk of memory and use it however you want. And you can interpret it how it is appropriate for your use case, for example reading it into a string, or an int.

Except these days with strict aliasing that's not true. If you access memory through a pointer of the wrong type, you've probably committed the crime of undefined behavior, for which the compiler might punish you by breaking your code - but probably won't, leaving the bug to be triggered in the future by some random code change or compiler upgrade that creates an optimization opportunity.

Admittedly there are ways to avoid undefined behavior, but still. C gives the compiler a lot of leeway to mess around with your code.

[feelix]

Strict aliasing does not preclude using the bytes however you want. All that does is prohibit type casting in certain situations. By using different syntax you can still interpret the bytes how you want to (even if, in extreme situations, you might have to resort to using a memcmp in order to do so).

[milesrout]

'Strict aliasing' is a dangerous optimisation that OpenBSD's gcc-local disables for a reason.

[GlitchMr]

Not really that dangerous, I think it's more of an issue of having code written before strict aliasing rule.

Essentially, what strict aliasing rule requires is that user cannot go crazy casting pointers. Casting float pointer to int pointer is completely wrong. The exception is that it's completely safe to cast values to char pointer or void pointer (and back, but only to original type of a pointer). Objects of different types cannot use the same memory area.

What this usually affects is code that parses external data into a structure. This can be dealt with by use of `memcpy` (to copy data from char array into a structure) instead of pointer casts, which is mostly safe as far C specification is concerned (mostly because C specification doesn't really define stuff like paddings, so you need to be careful about that). There is also an option of using `union` which is allowed by C11 specification (but compilers released with C11 that had strict aliasing optimization didn't break code that had aliasing through union and even documented that).

[milesrout]

Not really that dangerous, except for all the code for which it is dangerous?

Of course, you've got me, it only breaks existing code, and doesn't affect code that's written perfectly according to the rules of C and not peoples' intuitions about what pointers actually mean on a hardware level.

It's not even safe to do this:

    struct a {
        int x;
    };
    struct b {
        int x;
        int y;
    };

    struct b b;
    struct a *a = &b;

You have to write b like this:

    struct b {
        struct a inner;
        int y;
    };