What is the strict aliasing rule?

Question: When asking about common undefined behavior in C, people sometimes refer to the strict aliasing rule.
What are they talking about?
Comment: May also want to see an article I wrote recently [What is the Strict Aliasing Rule and Why do we care?](https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8). It covers a lot of material not covered here or in some areas a more modern approach.
Comment: Most strict aliasing violations are violations of https://eel.is/c++draft/basic.lval#11 in the C++ standard. (or the corresponding rule in the C standard)
Answer: A typical situation where you encounter strict aliasing problems is when overlaying a struct (like a device/network msg) onto a buffer of the word size of your system (like a pointer to uint32_ts or uint16_ts). When you overlay a struct onto such a buffer, or a buffer onto such a struct through pointer casting you can easily violate strict aliasing rules.
So in this kind of setup, if I want to send a message to something I'd have to have two incompatible pointers pointing to the same chunk of memory. I might then naively code something like this:
typedef struct Msg
{
    unsigned int a;
    unsigned int b;
} Msg;

void SendWord(uint32_t);

int main(void)
{
    // Get a 32-bit buffer from the system
    uint32_t* buff = malloc(sizeof(Msg));

    // Alias that buffer through message
    Msg* msg = (Msg*)(buff);

    // Send a bunch of messages
    for (int i = 0; i < 10; ++i)
    {
        msg->a = i;
        msg->b = i+1;
        SendWord(buff[0]);
        SendWord(buff[1]);
    }
}

The strict aliasing rule makes this setup illegal: dereferencing a pointer that aliases an object that is not of a compatible type or one of the other types allowed by C 2011 6.5 paragraph 71 is undefined behavior. Unfortunately, you can still code this way, maybe get some warnings, have it compile fine, only to have weird unexpected behavior when you run the code.
(GCC appears somewhat inconsistent in its ability to give aliasing warnings, sometimes giving us a friendly warning and sometimes not.)
To see why this behavior is undefined, we have to think about what the strict aliasing rule buys the compiler. Basically, with this rule, it doesn't have to think about inserting instructions to refresh the contents of buff every run of the loop. Instead, when optimizing, with some annoyingly unenforced assumptions about aliasing, it can omit those instructions, load buff[0] and buff[1] into CPU registers once before the loop is run, and speed up the body of the loop. Before strict aliasing was introduced, the compiler had to live in a state of paranoia that the contents of buff could change by any preceding memory stores. So to get an extra performance edge, and assuming most people don't type-pun pointers, the strict aliasing rule was introduced.
Keep in mind, if you think the example is contrived, this might even happen if you're passing a buffer to another function doing the sending for you, if instead you have.
void SendMessage(uint32_t* buff, size_t size32)
{
    for (int i = 0; i < size32; ++i)
    {
        SendWord(buff[i]);
    }
}

And rewrote our earlier loop to take advantage of this convenient function
for (int i = 0; i < 10; ++i)
{
    msg->a = i;
    msg->b = i+1;
    SendMessage(buff, 2);
}

The compiler may or may not be able to or smart enough to try to inline SendMessage and it may or may not decide to load or not load buff again. If SendMessage is part of another API that's compiled separately, it probably has instructions to load buff's contents. Then again, maybe you're in C++ and this is some templated header only implementation that the compiler thinks it can inline. Or maybe it's just something you wrote in your .c file for your own convenience. Anyway undefined behavior might still ensue. Even when we know some of what's happening under the hood, it's still a violation of the rule so no well defined behavior is guaranteed. So just by wrapping in a function that takes our word delimited buffer doesn't necessarily help.
So how do I get around this?

Use a union. Most compilers support this without complaining about strict aliasing. This is allowed in C99 and explicitly allowed in C11.
  union {
      Msg msg;
      unsigned int asBuffer[sizeof(Msg)/sizeof(unsigned int)];
  };

You can disable strict aliasing in your compiler (f[no-]strict-aliasing in gcc))

You can use char* for aliasing instead of your system's word. The rules allow an exception for char* (including signed char and unsigned char). It's always assumed that char* aliases other types. However this won't work the other way: there's no assumption that your struct aliases a buffer of chars.

Beginner beware
This is only one potential minefield when overlaying two types onto each other. You should also learn about endianness, word alignment, and how to deal with alignment issues through packing structs correctly.
Footnote
1 The types that C 2011 6.5 7 allows an lvalue to access are:

a type compatible with the effective type of the object,
a qualified version of a type compatible with the effective type of the object,
a type that is the signed or unsigned type corresponding to the effective type of the object,
a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
a character type.
Comment: @Matthieu: Signedness makes no difference to alias rules, so using `unsigned char *` is okay.
Comment: Isn't it undefined behaviour to read from an union member different from the last one written to?
Comment: Bollocks, this answer is *completely backwards*. The example it shows as illegal is actually legal, and the example it shows as legal is actually illegal.
Comment: I am coming after the battle it seems.. may `unsigned char*` be used far `char*` instead ? I tend to use `unsigned char` rather than `char` as the underlying type for `byte` because my bytes are not signed and I don't want the weirdness of signed behavior (notably wrt to overflow)
Comment: This example is unclear. It shows `unsigned int` being aliased as `uint32_t`. However it is implementation-defined whether `unsigned int` is compatible with `uint32_t`. If `uint32_t` is a typedef for `unsigned int` then the code actually has no strict aliasing violation, otherwise it does.  I'd suggest editing it so that the two types are clearly incompatible.
Comment: Your `uint32_t* buff = malloc(sizeof(Msg));` and the subsequent union `unsigned int asBuffer[sizeof(Msg)];` buffer declarations will have different sizes and neither is correct. The `malloc` call is relying on the 4 byte alignment under the hood (don't do it) and the union will be 4 times bigger than it needs to be... I understand that it is for clarity but it bugs me none-the-less...
Comment: @Grzegorz: So use `-fno-strict-aliasing` when you compile, but then you aren't using C (or C++).  Anyway, both pieces of code in your comment are wrong.  The second won't even compile, since you have mismatching indirection in an initialization.
Comment: As per my comment to http://stackoverflow.com/questions/6359629/union-hack-for-endian-testing-and-byte-swapping/6359836#6359836: _C99 says that the bytes that don't correspond to the last stored member take unspecified values (potentially implying that it's legal to read from members which share all its bytes with the last stored member), but then lists reading from a member other than the last stored as UB. C1X changes that, defining as UB reading from bytes that do not correspond to the last stored member._
Comment: @nubok: see the [answer](http://stackoverflow.com/a/7005988/15168) by [Ben Voigt](http://stackoverflow.com/users/103167/ben-voigt).  The relevant paragraph of the C standard explicitly says 'character type' and does not mention '`void`' or '`void` pointer' at all.
Comment: This answer does not define what strict aliasing is. I also think this example is not correct, since the memory is being accessed by a struct that contains compatible types to the effective type of the memory (unsigned, assuming 32 bit values everywhere).
Comment: The example has drifted over time, and it now needs to be cleaned up. SendWord is declared to take a pointer-to-uint32_t, but it is then called on a uint32_t. And the commend "// Get a 32-bit buffer from the system" precedes an allocation of sizeof(Msg), which will be 64 bits on most popular implementations. I can't tell which errors are intentional, to point out the violation of strict aliasing, and which are accidents. What is the intended meaning?
Comment: @Nubcake: Because, in the words of the Committee expressed in the published Rationale, when the Standard use the term "Undefined Behavior", it among other things, "...identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior."  A religion has formed around the idea the Standard characterizes as "broken" any program whose behavior it regards as UB, ignoring the fact that the phrase "non-portable or erroneous" in no way excludes "non-portable but correct".
Comment: To address @nonsensickle's observation, the union declaration should have this member declaration instead: `unsigned int asBuffer[sizeof(Msg)/sizeof(unsigned int)]`.
Comment: @this all is forgiven. This is a hard topic and I appreciate having an opportunity to double check :)
Comment: @Grzegorz What makes you think that `int* i=*(int*)b; *i=0;` works?
Comment: This code is total garbage.  The signature for `main` is wrong. It either needs to use `struct Msg` or add `typedef struct Msg Msg;` The type of `Sendword()`'s argument in wrong. It doesn't have the needed `#include`s. And older compilers won't accept the `for ( int i ...` construct.
Comment: @lanyusea: The "strict aliasing rule" will improve the performance of programs that still work, but gcc/clang interpretation will cause some programs that would have behaved usefully to instead behave nonsensically.  The Standard can be interpreted in a way that would allow 90% of the performance improvements, plus some that clang/gcc miss, while still processing most of the useful constructs that are broken by their interpretation, but the authors of clang/gcc are heavily invested in their refusal to interpret it in such fashion.
Comment: -1 The code examples in the answer code won't compile as C99.
Comment: Isn't the "wrong" example on top well defined if uint32_t is a typedef for unsigned int? Because `Msg` qualifies for "an aggregate or union type that includes one of the aforementioned types [here: uint32_t. -ps] among its elements", doesn't it?
Comment: I think you need to reconsider your example, if *uint32_t* is *unsigned int* then given my [answer here](http://stackoverflow.com/a/27914489/1708801) there should be no strict aliasing violation.
Comment: @DougT. I appears I though you were sending msg instead of buff, which is violating strict aliasing( so the code is correct ). My bad :-////.
Comment: @curiousguy: I am afraid I do not understand the question :) Can you rephrase it, please? If it still matters, of course.
Comment: @JohnHascall Thanks. You're right. I'd love to see it cleaned up. Its community wiki, do you have enough rep to edit it?
Comment: will the strict aliasing rule breaking make our program slower? or the compiler still optimize the code in that way but may cause some undefined behavior like SIGBUS?
Comment: It should also be clarified that this answer is intended to be a C answer (although it is completely wrong for C as well)  ; the question is dual-tagged C and C++.
Comment: @Doug T.: as I understand, the same problem is on receiving side too when `StupidAPI` casts back to `Msg`, right? And how using `char*` instead of `unsigned int*` would improve this?
Comment: @R.MartinhoFernandes I reworked this answer quite a bit to hopefully be more accurate and clarify things. In the original example it was assumed that SendToStupidApi would dereference the type punned pointer thus violating strict aliasing. I also took out the reinterpret_cast that is of course not C. And added a note that the union solution violates the spec but is supported by most compilers.
Comment: I don't think the union solution violates the intent of C99, and it does not violate C11 (it was removed from appendix J). See: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm
Comment: Great answer. I have a similar question where I had to alias a struct onto a char array because I had to portably ensure alignment of the struct's memory. http://stackoverflow.com/questions/14170010/strict-aliasing-and-memory-alignment
Comment: The answer tells using char* avoids this problem. Doesn't also passing the buffer as a void* parameter of a function solve this problem?
Comment: I can't stand the fact that `char b[4]; *(int*)b=0;` does not work but `int* i=*(int*)b; *i=0;` does. I am calling for creating an anti strict aliasing movement where optimizer is forcing people to add extra declarations to avoid the issue. I understand that there can be some special case where warning actually should be an error but in the example above? come on! I am working on an old code that did not have this problem before, and I have hundreds of places to 'fix' (make less readable.)
Comment: @DavidRTribble Thanks for addressing it. May I also suggest to you to mention the other two options that [this article](http://dbp-consulting.com/tutorials/StrictAliasing.html) talks about, i.e. **memcpy** and the **restrict** keyword, in your answer (for completeness)? Other than that, good work! Tough topic...
Comment: I think the issue of optimizations that may or may not be possible can actually be unhelpful sometimes. The reason I say this is the I have constructed code where such optimizations weren't possible anyway, and was still told that the code is UB. So maybe, the optimization story is part of the *history* of the strict aliasing rule; but today, the today the *effect* of the rule is more drastic. Casting a pointer, and immediately reading from it, will be undefined generally (except for the specific exceptions around unions and compatible types).
Comment: @Grzegorz "_I can't stand the fact that_" source?
Comment: @ChrisCulter I believe my original intention many many years back was to have those `unsigned ints` be 32 bits.
Comment: @Doug T. I don't think I do
Comment: @DougT. what does "use a union" mean in your answer.  I ask because searching i cannot find a definitive answer.  As far as i can understand (And im not 100% sure on this) - It seems that if you cast to the union* it is still undefined and that in order for it to be defined you need to first copy the data to a union access it through the type-pun built into the union.
Comment: @skimon what you say sounds right to me (I learned about strict aliasing ~10 hrs ago, however). You need to access the data in the union directly from a union member, not an alias to the union member. If you read the `-fstrict_aliasing` flag in this `gcc` manual, it has an example of unions: https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc.pdf on page 149. Of course this is just `gcc` and not the `C` or `C++` standards.
Comment: It may be worthwhile to note that the list of allowed types does *not* allow for a struct or union object to be accessed using lvalues of member type.  A quality compiler should treat an access to an lvalue or pointer which is freshly derived from one of another type as an access to the original object, but a compiler's ability to recognize such things is a Quality of Implementation issue rather than a conformance one, and the Standard deliberately makes no attempt to mandate that implementations be of adequate quality to be suitable for any particular purpose.
Comment: @skimon: Code that does almost *anything* with structs or unions will be reliant upon compilers writers to refrain from doing stupid things that the Standard would allow.  Something like `struct S { int x; } s = {0}; s.x=1;` invokes UB because `int` is not one of the types that may be used to access an object of type `struct S`.  Obviously a compiler would have to be really stupid not to process something like that in useful fashion, and I don't know of any that are deliberately *that* bad, but some seem read the Standard as inviting behaviors that are almost as dumb.
Comment: On a 32 bit machine, malloc(sizeof(Msg)) returns a 64 bit buffer, and on a 64 bit machine, it returs a 128 bit buffer. It's a 32-bit buffer only on 16-bit machines.
Comment: Also, you *should* free malloc'd memory.
Comment: Msg *msg = (Msg*)malloc(sizeof(Msg));  will this violate strict aliasing?
Comment: Can anybody elaborate on *"an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)"*. What does it exactly mean, and how is this exception to the rule commonly used?
Comment: I'm a little bit confused, why would you ever want to use `-fno-strict-aliasing` if violating the strict aliasing rule causes UB?
Comment: Adding the definition of 'effective type', including an exact standard reference, would improve this answer a lot. I take it the effectice type is the last type information that has been used for the object, if there is any [(taken from here, but this doesn't point to the standard)](https://riptutorial.com/c/example/18843/effective-type)
Answer: The best explanation I have found is by Mike Acton, Understanding Strict Aliasing. It's focused a little on PS3 development, but that's basically just GCC.
From the article:

"Strict aliasing is an assumption, made by the C (or C++) compiler, that dereferencing pointers to objects of different types will never refer to the same memory location (i.e. alias each other.)"

So basically if you have an int* pointing to some memory containing an int and then you point a float* to that memory and use it as a float you break the rule. If your code does not respect this, then the compiler's optimizer will most likely break your code.
The exception to the rule is a char*, which is allowed to point to any type.
Comment: @davmac: The authors of C89 never intended that it should force programmers to jump through hoops.  I find thoroughly bizarre the notion that a rule that exists for the sole purpose of optimization should be interpreted in such fashion as to require programmers to write code that redundantly copies data in the hopes that an optimizer will remove the redundant code.
Comment: @curiousguy: False. Firstly, the original conceptual idea behind unions was that at any moment there's **only one** member object "active" in the given union object, while the others simply don't exist. So, there are no "different objects at the same address" as you seem to believe. Secondly, aliasing violations everyone is talking about is about **accessing** one object as a different object, not about simply *having* two objects with the same address. As long as there is no type-punning **access**, there no problem. That was the original idea. Later, type-punning through unions was allowed.
Comment: So what is the canonical way to legally use the same memory with variables of 2 different types? or does everyone just copy?
Comment: Mike Acton's page is flawed. The part of "Casting through a union (2)", at least, is downright wrong; the code he claims is legal is not.
Comment: The exception is wider than `char *` --> Applies to any character type.
Comment: @curiousguy: "Can't have unions"? Firstly, the original/primary purpose of unions is not in any way related to aliasing at all. Secondly, the modern language spec explicitly permits using unions for aliasing. The compiler is required to notice that a union is used and treat the situation is a special way.
Comment: @AnT "_the original/primary purpose of unions is not in any way related to aliasing at all_" What? That's the only purpose of a union. **That the definition of a union: different objects at the same address**.
Comment: @curiousguy: By definition, writing into a union member *"activates"* that member and *"deactivates"* all other members.
Comment: The link is broken. Archived link: https://web.archive.org/web/20171221170757/http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
Comment: @curiousguy: The question of when compilers must recognize derived pointers and lvalues is a quality-of-implementation issue, and the authors of the Standard deliberately refrained from trying to mandate that conforming implementations must be of sufficient quality to be useful for any particular purpose.  I doubt they imagined that compiler writers would try to use the standard to justify writing low-quality implementations.
Comment: @Antonio: The link works for me. Maybe a temporary or regional issue. If the problem occurs again, please link to [the latest snapshot in Internet Archive](http://web.archive.org/web/20170908112042/http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html).
Comment: @Antonio: Just checked again, and when I click the link in this answer, I get the right article, no 404. Firefox 56 on Windows 10. No idea where this might have gone wrong for you.
Comment: @Palec Pretty amazing, must be something with my work network. Indeed on my Android phone it loads.
Comment: There are other contexts in C language which might produce "different objects at the same address". For example, declaring `int a[2]; double b;` might result in the "imaginary" array element `a[2]` having the same address as `b`. The language does not consider this a problem. You just have to remember that only `b` is accessible, while `a[2]` can only be "pointed to", but cannot be accessed.
Comment: @AnT Then how do you write to a member of a union B after a member A has been written?
Comment: @AnT And how would you do that? Is there an operator "activate" in C?
Comment: Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/159911/discussion-between-curiousguy-and-ant).
Comment: @curiousguy: With regard to the code in the chat, a quality compiler will recognize that an access made to an lvalue or pointer which is freshly derived from one of another type as being an access or potential access to the original.  So given `int *p = u.a;`, a quality compiler should recognize accesses to `*p` as accesses to `u` until code does something else `u` without involving `a`, or execution enters a function or loop wherein that occurs.  Since the lvalue `u` is allowed to access any members thereof, pointers that are freshly derived from it should be able to do likewise.
Comment: @AnT: The special guarantees about Common Initial Sequences were part of C before unions were.  If would be meaningless to guarantee that any part of a Common Initial Sequence can be inspected using any structure type that contains it, if the corresponding portions of the structs in question didn't exist simultaneously.
Answer: Note
This is excerpted from my "What is the Strict Aliasing Rule and Why do we care?" write-up.
What is strict aliasing?
In C and C++ aliasing has to do with what expression types we are allowed to access stored values through. In both C and C++ the standard specifies which expression types are allowed to alias which types. The compiler and optimizer are allowed to assume we follow the aliasing rules strictly, hence the term strict aliasing rule. If we attempt to access a value using a type not allowed it is classified as undefined behavior (UB). Once we have undefined behavior all bets are off, the results of our program are no longer reliable.
Unfortunately with strict aliasing violations, we will often obtain the results we expect, leaving the possibility the a future version of a compiler with a new optimization will break code we thought was valid. This is undesirable and it is a worthwhile goal to understand the strict aliasing rules and how to avoid violating them.
To understand more about why we care, we will discuss issues that come up when violating strict aliasing rules, type punning since common techniques used in type punning often violate strict aliasing rules and how to type pun correctly.
Preliminary examples
Let's look at some examples, then we can talk about exactly what the standard(s) say, examine some further examples and then see how to avoid strict aliasing and catch violations we missed. Here is an example that should not be surprising (live example):
int x = 10;
int *ip = &x;

std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";

We have a int* pointing to memory occupied by an int and this is a valid aliasing. The optimizer must assume that assignments through ip could update the value occupied by x.
The next example shows aliasing that leads to undefined behavior (live example):
int foo( float *f, int *i ) {
    *i = 1;
    *f = 0.f;

    return *i;
}

int main() {
    int x = 0;

    std::cout << x << "\n";   // Expect 0
    x = foo(reinterpret_cast<float*>(&x), &x);
    std::cout << x << "\n";   // Expect 0?
}

In the function foo we take an int* and a float*, in this example we call foo and set both parameters to point to the same memory location which in this example contains an int. Note, the reinterpret_cast is telling the compiler to treat the expression as if it had the type specified by its template parameter. In this case we are telling it to treat the expression &x as if it had type float*. We may naively expect the result of the second cout to be 0 but with optimization enabled using -O2 both gcc and clang produce the following result:
0
1

Which may not be expected but is perfectly valid since we have invoked undefined behavior. A float can not validly alias an int object. Therefore the optimizer can assume the constant 1 stored when dereferencing i will be the return value since a store through f could not validly affect an int object. Plugging the code in Compiler Explorer shows this is exactly what is happening(live example):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret

The optimizer using Type-Based Alias Analysis (TBAA) assumes 1 will be returned and directly moves the constant value into register eax which carries the return value. TBAA uses the languages rules about what types are allowed to alias to optimize loads and stores. In this case TBAA knows that a float can not alias an int and optimizes away the load of i.
Now, to the Rule-Book
What exactly does the standard say we are allowed and not allowed to do? The standard language is not straightforward, so for each item I will try to provide code examples that demonstrates the meaning.
What does the C11 standard say?
The C11 standard says the following in section 6.5 Expressions paragraph 7:

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:88)
— a type compatible with the effective type of the object,

int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int

— a qualified version of a type compatible with the effective type of the object,

int x = 1;
const int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type const int which is compatible with int

— a type that is the signed or unsigned type corresponding to the effective type of the object,

int x = 1;
unsigned int *p = (unsigned int*)&x;
printf("%u\n", *p ); // *p gives us an lvalue expression of type unsigned int which corresponds to
                     // the effective type of the object

gcc/clang has an extension and also that allows assigning unsigned int* to int* even though they are not compatible types.

— a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,

int x = 1;
const unsigned int *p = (const unsigned int*)&x;
printf("%u\n", *p ); // *p gives us an lvalue expression of type const unsigned int which is a unsigned type
                     // that corresponds with to a qualified version of the effective type of the object

— an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or

struct foo {
    int x;
};

void foobar( struct foo *fp, int *ip );  // struct foo is an aggregate that includes int among its members so it
                                         // can alias with *ip

foo f;
foobar( &f, &f.x );

— a character type.

int x = 65;
char *p = (char *)&x;
printf("%c\n", *p );  // *p gives us an lvalue expression of type char which is a character type.
                      // The results are not portable due to endianness issues.

What the C++17 Draft Standard says
The C++17 draft standard in section [basic.lval] paragraph 11 says:

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:63

(11.1) — the dynamic type of the object,

void *p = malloc( sizeof(int) ); // We have allocated storage but not started the lifetime of an object
int *ip = new (p) int{0};        // Placement new changes the dynamic type of the object to int
std::cout << *ip << "\n";        // *ip gives us a glvalue expression of type int which matches the dynamic type
                                 // of the allocated object

(11.2) — a cv-qualified version of the dynamic type of the object,

int x = 1;
const int *cip = &x;
std::cout << *cip << "\n";  // *cip gives us a glvalue expression of type const int which is a cv-qualified
                            // version of the dynamic type of x

(11.3) — a type similar (as defined in 7.5) to the dynamic type of the object,

(11.4) — a type that is the signed or unsigned type corresponding to the dynamic type of the object,

// Both si and ui are signed or unsigned types corresponding to each others dynamic types
// We can see from this godbolt(https://godbolt.org/g/KowGXB) the optimizer assumes aliasing.
signed int foo( signed int &si, unsigned int &ui ) {
    si = 1;
    ui = 2;

    return si;
}

(11.5) — a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,

signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing

(11.6) — an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union),

struct foo {
    int x;
};

// Compiler Explorer example(https://godbolt.org/g/z2wJTC) shows aliasing assumption
int foobar( foo &fp, int &ip ) {
    fp.x = 1;
    ip = 2;

    return fp.x;
}

foo f;
foobar( f, f.x );

(11.7) — a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,

struct foo { int x; };

struct bar : public foo {};

int foobar( foo &f, bar &b ) {
    f.x = 1;
    b.x = 2;

    return f.x;
}

(11.8) — a char, unsigned char, or std::byte type.

int foo( std::byte &b, uint32_t &ui ) {
    b = static_cast<std::byte>('a');
    ui = 0xFFFFFFFF;

    return std::to_integer<int>( b );  // b gives us a glvalue expression of type std::byte which can alias
                                       // an object of type uint32_t
}

Worth noting signed char is not included in the list above, this is a notable difference from C which says a character type.
What is Type Punning
We have gotten to this point and we may be wondering, why would we want to alias for? The answer typically is to type pun, often the methods used violate strict aliasing rules.
Sometimes we want to circumvent the type system and interpret an object as a different type. This is called type punning, to reinterpret a segment of memory as another type. Type punning is useful for tasks that want access to the underlying representation of an object to view, transport or manipulate. Typical areas we find type punning being used are compilers, serialization, networking code, etc…
Traditionally this has been accomplished by taking the address of the object, casting it to a pointer of the type we want to reinterpret it as and then accessing the value, or in other words by aliasing. For example:
int x = 1;

// In C
float *fp = (float*)&x;  // Not a valid aliasing

// In C++
float *fp = reinterpret_cast<float*>(&x);  // Not a valid aliasing

printf( "%f\n", *fp );

As we have seen earlier this is not a valid aliasing, so we are invoking undefined behavior. But traditionally compilers did not take advantage of strict aliasing rules and this type of code usually just worked, developers have unfortunately gotten used to doing things this way. A common alternate method for type punning is through unions, which is valid in C but undefined behavior in C++ (see live example):
union u1
{
    int n;
    float f;
};

union u1 u;
u.f = 1.0f;

printf( "%d\n", u.n );  // UB in C++ n is not the active member

This is not valid in C++ and some consider the purpose of unions to be solely for implementing variant types and feel using unions for type punning is an abuse.
How do we Type Pun correctly?
The standard method for type punning in both C and C++ is memcpy. This may seem a little heavy handed but the optimizer should recognize the use of memcpy for type punning and optimize it away and generate a register to register move. For example if we know int64_t is the same size as double:
static_assert( sizeof( double ) == sizeof( int64_t ) );  // C++17 does not require a message

we can use memcpy:
void func1( double d ) {
    std::int64_t n;
    std::memcpy(&n, &d, sizeof d);
    //...

At a sufficient optimization level any decent modern compiler generates identical code to the previously mentioned reinterpret_cast method or union method for type punning. Examining the generated code we see it uses just register mov (live Compiler Explorer Example).
C++20 and bit_cast
In C++20 we may gain bit_cast (implementation available in link from proposal) which gives a simple and safe way to type-pun as well as being usable in a constexpr context.
The following is an example of how to use bit_cast to type pun a unsigned int to float, (see it live):
std::cout << bit_cast<float>(0x447a0000) << "\n"; //assuming sizeof(float) == sizeof(unsigned int)

In the case where To and From types don't have the same size, it requires us to use an intermediate struct15. We will use a struct containing a sizeof( unsigned int ) character array (assumes 4 byte unsigned int) to be the From type and unsigned int as the To type.:
struct uint_chars {
    unsigned char arr[sizeof( unsigned int )] = {};  // Assume sizeof( unsigned int ) == 4
};

// Assume len is a multiple of 4
int bar( unsigned char *p, size_t len ) {
    int result = 0;

    for( size_t index = 0; index < len; index += sizeof(unsigned int) ) {
        uint_chars f;
        std::memcpy( f.arr, &p[index], sizeof(unsigned int));
        unsigned int result = bit_cast<unsigned int>(f);

        result += foo( result );
    }

    return result;
}

It is unfortunate that we need this intermediate type but that is the current constraint of bit_cast.
Catching Strict Aliasing Violations
We don't have a lot of good tools for catching strict aliasing in C++, the tools we have will catch some cases of strict aliasing violations and some cases of misaligned loads and stores.
gcc using the flag -fstrict-aliasing and -Wstrict-aliasing can catch some cases although not without false positives/negatives. For example the following cases will generate a warning in gcc (see it live):
int a = 1;
short j;
float f = 1.f; // Originally not initialized but tis-kernel caught
               // it was being accessed w/ an indeterminate value below

printf("%i\n", j = *(reinterpret_cast<short*>(&a)));
printf("%i\n", j = *(reinterpret_cast<int*>(&f)));

although it will not catch this additional case (see it live):
int *p;

p = &a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));

Although clang allows these flags it apparently does not actually implement the warnings.
Another tool we have available to us is ASan which can catch misaligned loads and stores. Although these are not directly strict aliasing violations they are a common result of strict aliasing violations. For example the following cases will generate runtime errors when built with clang using -fsanitize=address
int *x = new int[2];               // 8 bytes: [0,7].
int *u = (int*)((char*)x + 6);     // regardless of alignment of x this will not be an aligned address
*u = 1;                            // Access to range [6-9]
printf( "%d\n", *u );              // Access to range [6-9]

The last tool I will recommend is C++ specific and not strictly a tool but a coding practice, don't allow C-style casts. Both gcc and clang will produce a diagnostic for C-style casts using -Wold-style-cast. This will force any undefined type puns to use reinterpret_cast, in general reinterpret_cast should be a flag for closer code review. It is also easier to search your code base for reinterpret_cast to perform an audit.
For C we have all the tools already covered and we also have tis-interpreter, a static analyzer that exhaustively analyzes a program for a large subset of the C language. Given a C version of the earlier example where using -fstrict-aliasing misses one case (see it live)
int a = 1;
short j;
float f = 1.0;

printf("%i\n", j = *((short*)&a));
printf("%i\n", j = *((int*)&f));

int *p;

p = &a;
printf("%i\n", j = *((short*)p));

tis-interpeter is able to catch all three, the following example invokes tis-kernel as tis-interpreter (output is edited for brevity):
./bin/tis-kernel -sa example1.c
...
example1.c:9:[sa] warning: The pointer (short *)(& a) has type short *. It violates strict aliasing
              rules by accessing a cell with effective type int.
...

example1.c:10:[sa] warning: The pointer (int *)(& f) has type int *. It violates strict aliasing rules by
              accessing a cell with effective type float.
              Callstack: main
...

example1.c:15:[sa] warning: The pointer (short *)p has type short *. It violates strict aliasing rules by
              accessing a cell with effective type int.

Finally there is TySan which is currently in development. This sanitizer adds type checking information in a shadow memory segment and checks accesses to see if they violate aliasing rules. The tool potentially should be able to catch all aliasing violations but may have a large run-time overhead.
Comment: Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackoverflow.com/rooms/177456/discussion-on-answer-by-shafik-yaghmour-what-is-the-strict-aliasing-rule).
Answer: This is the strict aliasing rule, found in section 3.10 of the C++03 standard (other answers provide good explanation, but none provided the rule itself):

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined:

the dynamic type of the object,
a cv-qualified version of the dynamic type of the object,
a type that is the signed or unsigned type corresponding to the dynamic type of the object,
a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union),
a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
a char or unsigned char type.

C++11 and C++14 wording (changes emphasized):

If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

the dynamic type of the object,
a cv-qualified version of the dynamic type of the object,
a type similar (as defined in 4.4) to the dynamic type of the object,
a type that is the signed or unsigned type corresponding to the dynamic type of the object,
a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,
an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union),
a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
a char or unsigned char type.

Two changes were small: glvalue instead of lvalue, and clarification of the aggregate/union case.
The third change makes a stronger guarantee (relaxes the strong aliasing rule): The new concept of similar types that are now safe to alias.

Also the C wording (C99; ISO/IEC 9899:1999 6.5/7; the exact same wording is used in ISO/IEC 9899:2011 §6.5 ¶7):

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types  73) or 88):

a type compatible with the effective type of the object,
a qualified version of a type compatible with the effective type of
the object,
a type that is the signed or unsigned type corresponding to the
effective type of the object,
a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
a character type.

 73) or 88) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
Comment: @supercat: The way the rule for structures is worded, the actual access is always to the primitive type.  Then access via a reference to the primitive type is legal because the types match, and access via a reference to the containing structure type is legal because it's specially permitted.
Comment: If one has an lvalue of a structure type, takes the address of a member, and passes that to a function that uses it as a pointer to the member type, would that be regarded as accessing an object of the member type (legal), or an object of the structure type (forbidden)?  A *lot* of code assumes it's legal to access structures in such fashion, and I think a lot of people would squawk at a rule which was understood as forbidding such actions, but it's unclear what the exact rules are.  Further, unions and structures are treated the same, but sensible rules for each should be different.
Comment: @BenVoigt: I don't think the common initial sequence works unless accesses are done via the union.  See http://goo.gl/HGOyoK to see what gcc is doing.  If accessing an lvalue of union type via an lvalue of a member type (not using union-member-access operator) was legal, then `wow(&u->s1,&u->s2)` would need to be legal even when a pointer is used to modify `u`, and that would negate most optimizations that the aliasing rule was designed to facilitate.
Comment: Look at the C89 Rationale http://www.cs.technion.ac.il/users/yechiel/CS/C++draft/rationale.pdf section 3.3 which talks about it.
Comment: @BenVoigt: Under that interpretation, if `S1` and `S2` are structures with `int x;` as their first field, and which require nothing coarser than `int` alignment, then given `void blah(S1 *p1, S2, *p2`);` a compiler would not be allowed to make any assumptions about aliasing between `p1->x` and `p2->x`.  because they could both identify storage of type `int`.  I don't think that's what was intended.
Comment: @supercat: Check out "common initial subsequence".  Aliasing between `p1->x` and `p2->x` is perfectly legal.
Comment: @supercat: Not really, common initial sequence only allows aliasing `int S1::x` with `int S2::x` and not `float S1::y` with `int S2::y`.  That's still a very powerful optimization rule.
Comment: @supercat: The rule is that a class that singly-inherits a standard-layout type and has no non-static data members of its own is also standard-layout.  Or if it inherits an empty base class, the derived type can add non-static data members and still be standard-layout.  But as soon as you have non-static data members at multiple different inheritance levels, you lose standard-layout.
Comment: @BenVoigt: It's too bad that the Standard didn't define separate "sizeof" and "strideof" operators; that wold have made it possible for an implementation allow objects to have a size which was not a multiple of their alignment.
Comment: @AvivCohn: To be super precise, the forbidden thing is accessing the object resulting from dereferencing.  Merely playing with pointer conversions and arithmetic cannot violate strict aliasing (although it may violate other rules).
Comment: @Kos: That's cool, thanks!  Can you also comment on whether strict aliasing was required by C89/90?  (I seem to recall not, that it was introduced at the same time as the `restrict` keyword, but I'm not sure).
Comment: How can you use an lvalue of class type?
Comment: @curiousguy: Any way that class allows.  Seriously, I'm not going to write you an entire C++ book listing all the things that you can do with a class instance.  One notable thing you *can't* do with an lvalue of class type is bind an rvalue reference to it.
Comment: @curiousguy: In `std::cout << "Hello World.\n";`, `std::cout` is an lvalue with class type.
Comment: @BenVoigt Are you saying "section 3.10 of the C++03 standard" applies to `std::cout`?
Comment: @BenVoigt: Given `union { struct S1 s1; struct S2 s2; } u;`, if both structures start with `int x`, then an assignment to `u.s1.x` is also an assignment to `u.s1.x`.  That doesn't imply that they legitimately alias when not accessed through union `u`.
Comment: @supercat: So you claim that it would be invalid to call `blah(&u.s1, &u.s2)`?  By what rule?
Comment: @BenVoigt: Given `typedef struct { int x; float y;} S1;
typedef struct { int x; int y;} S2;
typedef union { S1 s1; S2 s2;} U;

void wow1(S1 *p1, S2 *p2)
{
  p1->x++;
  p2->x^=1;
  p1->x--;
  p2->x^=1;
}` gcc will compile the function as a do-nothing-and-return.
Comment: @BenVoigt: If gcc sees the definition of `wow1` when it compiles a call to `wow(&u->s1, &u->s2);` it produces weird behavior which is consistent with neither the recognized-aliasing nor the non-aliasing case.
Comment: Hmm, I see that the common initial sequence rule only allows reading.  So we could do `bar(S1* p1, const S2* p2) { p1->x = p2->x+1; p1->x = p2->x-1; }` and see what happens.  Could be that gcc doesn't implement common initial sequence correctly.
Comment: @supercat: Also, why are you using `typedef`?  We're talking about C++ aren't we?
Comment: @BenVoigt: My focus is on C, though gcc behavior here is identical in both C and C++ modes.  In C++ the proper way to create structures with a recognized common initial subsequence would be to use inheritance, which would clearly be 100% legal, but that's not an option in C.
Comment: @supercat: Actually, you couldn't use inheritance and the union.  Common initial sequence rule only applies to standard-layout types, which is broken by inheritance.
Comment: @BenVoigt: Though even in C++, I think that if S1 and S2 shared a common base SB, it would be legal to alias an S1* and an SB*, or an S2* and an SB*, but not to alias an S1* with an S2* even if code was only using members common to both.
Comment: @BenVoigt: Is it not possible to use inheritance with PODS?  The only case where a compiler would have to store any type-related information when inheriting from a PODS and not adding any virtual members would be if it were legal to use `delete` on a base-type pointer to eliminate a derived-type object, and I don't think that's legal, is it?
Comment: @BenVoigt: My suspicion is that the rules almost "work", but that the rule would be useless for compilers if it didn't let them pretend some defined behavior was UB, and would make the language almost useless for programmers if compilers didn't treat some forms of UB predictably.
Comment: @BenVoigt: Hmm... that seems a shame, since there should be a useful way of creating a type whose layout was equivalent to `struct derived1 { base1 b; int anothermember;}` and allowing it to be used as either a `base1` or ` derived1`, without having to use `b.` to access base members.
Comment: @supercat: Consider: `struct B { double x; char y; };  struct D1 : B { char z; }; struct D2 { B b; char z; };`  Is it legal for `D1::z` to overlap the padding in `D1::B`?  What about `D2::z` and `D2::b` ?  (Assume an 8-bit machine so that `sizeof(double) == alignof(double) = 8`)
Comment: @BenVoigt: Your point being that it is worthwhile to allow a derived type to be smaller than the sum of the base type and the new elements?  I can see there would be benefit in that.  Still, I would suggest that the usefulness of both C and C++ will be significantly hampered if there's no way to have a function accept a pointer to an arbitrary structure type with a known initial prefix.  As noted, passing pointers to union members does not work, and there's no reason in the Standard why it should be legal to work with a pointer to even one union member if it's not legal to use more than that.
Comment: @supercat: Well, even with gcc's interpretation of strict aliasing, it is straightforward to "have a function accept a pointer to an arbitrary structure type with a known initial prefix".  It's only when you have two such pointers, that overlap, that trouble arises.  BTW my thought experiment is addressed here: http://stackoverflow.com/a/19950151/103167
Comment: @BenVoigt: The authors of gcc are very keen to point out that even if today's version of gcc lets programmers get away with violating the rules, programmers have no right to complain if tomorrow's gcc punishes them.  If the Standard says that code which receives a pointer to an arbitrary structure with a known initial prefix and uses it as a pointer to a different structure with the same prefix invokes UB, it doesn't matter what today's gcc does or does not do with such code.
Comment: @BenVoigt Does this https://stackoverflow.com/questions/34826036/dereferencing-this-pointer-gives-me-46-but-i-am-not-sure-why have undefined behaviour due to strict aliasing rule, or not,  I am little confused
Comment: @SurajJain: No, that one is ok.  The strict aliasing rule allows reading an object through both its actual type, and also through a `char*` (to see the individual bytes making up the object).
Comment: So I know this is old. Quick question: The last paragraph says "*... An object shall have its stored value accessed only by an lvalue expression that has one of the following types ...*". If the "object" is a pointer, is "its stored value" the address it stores, or the object pointed to by that address? The former option makes sense to me, the second not so much.
Comment: Phrased differently: Why is this code wrong? `A* a = malloc(sizeof(A)); B* b = (B*) a;`. Is it wrong because the stored value of `a` is an address to `A`, and the lvalue expression `B*` is not compatible with it? Or is it wrong because the stored value of `a` is an object of type `A`, and the lvalue `B` is not compatible with it?
Comment: @AvivCohn: It's not wrong.  `a` and `*a` are two different objects.  The access to `a` is fine, because it is done with type `A*` (the result of the access is then converted, but that doesn't change the access type).  Doing `*b` would be wrong.  Doing `A* c = (A*)b;` is fine and it is guaranteed that `c == a`.  Note that pointers from sources other than `malloc` could have alignment issues in addition to strict aliasing issues.
Comment: @BenVoigt So the only illegal thing in terms of strict aliasing is the actual *dereferencing*, right? Meaning we can assign pointers to different pointer types all we want, as long as dereferencing happens on a compatible pointer type?
Comment: @BenVoigt I understand. Quick question, actually clarifying what I meant to ask in the first place: As we know the standard says "*... An object shall have its stored value accessed only by an lvalue expression that has one of the following types ...*". In the case of a pointer-type, the "stored value" means the address stored in the variable, correct? I.e. - the stored value (the address) in the object (the pointer) can only be accessed by a compatible lvalue (one that describes a compatible pointer).
Comment: @AvivCohn: That's correct.  If in your example, the type `A` is actually `int*` and `B` is actually `float*` then `*b` will again lead to a strict aliasing violation.
Answer: Strict aliasing doesn't refer only to pointers, it affects references as well, I wrote a paper about it for the boost developer wiki and it was so well received that I turned it into a page on my consulting web site.  It explains completely what it is, why it confuses people so much and what to do about it. Strict Aliasing White Paper.  In particular it explains why unions are risky behavior for C++, and why using memcpy is the only fix portable across both C and C++.  Hope this is helpful.
Comment: Good paper. My take: (1) this aliasing-'problem' is an over-reaction to bad programming - trying to protect the bad programmer from his/her bad habits. If the programmer has good habits then this aliasing is just a nuisance and the checks can safely be turned off. (2) Compiler-side optimization should only be done in well-known cases and should when in doubt strictly follow the source-code; forcing the programmer to write code to cater for the compiler's idiosyncrasies is, simply put, wrong. Even worse to make it part of the standard.
Comment: @curiousguy: Having cleared up a few points of confusion, it is clear that the C language with the aliasing rules makes it impossible for programs to implement type-agnostic memory pools.  Some kinds of program can get by with malloc/free, but others need memory management logic better tailored to the tasks at hand.  I wonder why the C89 rationale used such a crummy example of the reason for the aliasing rule, since their example makes it seem like the rule won't pose any major difficulty in performing any reasonable task.
Comment: @curiousguy, most compiler suites out there are including -fstrict-aliasing as default on -O3 and this hidden contract is forced on the users who've never heard of the TBAA and wrote code like how a system programmer might. I don't mean to sound disingenuous to system programmers, but this kind of optimization should be left outside of default opt of -O3 and should be an opt-in optimization for those that know what TBAA is. It is not fun looking at compiler 'bug' that turns out to be user code violating TBAA, especially tracking down the source level violation in user code.
Comment: @slashmais (1) "_is an over-reaction to bad programming_" Nonsense. It is a rejection of the bad habits. *You do that? You pay the price: no guarantee for you!* (2) Well known cases? Which ones? The strict aliasing rule should be "well known"!
Comment: The "Another Broken version, referencing a twice" section of the paper makes no sense. Even if there were a sequence point, it would not give the right result. Perhaps you meant to use shift operators instead of shift assignments? But then the code is well-defined and does the right thing.
Comment: "_Strict aliasing doesn't refer only to pointers, it affects references as well_" Actually, it refers to **lvalues**. "_using memcpy is the only fix portable_" Hear!
Comment: @slashmais: I suspect that much of the horribleness of modern C stems from a belief that it is bad to add new directives and features to a language to tell a compiler what inferences it should make, but better to have the use of certain language features invoke inferences which, while consistent with the baseline requirements for what compilers must do, would break code that relies upon common and useful extensions that many implementations had historically provided at little or no cost.
Comment: @curiousguy: While I'm not privvy to all the discussions leading up to various versions of the Standard, I suspect a major problem was a political need to avoid declaring any members' implementations "non-normative".  It's useful to have a language which could be implemented on a sign-magnitude machine in such a fashion as to allow it to run a substantial fraction of code written in C.  It's far less useful to say that because the meaning of left-shifting a negative number or casting an oversized `unsigned value to `int` is not well-defined on such machines, the Standard should impose...
Comment: ...no requirements on the behavior of such operations even on two's-complement machines.  Further, there are many case where code which will work pre-2009 compilers totalling 99%+ of the market can be faster and more readable than any code which must meet the same requirements when fed into any actual or theoretical Standard-compliant compiler.  Failure to define a normative standard for behaviors which were widely-supported is detrimental to both source-code readability and machine-code efficiency--ironic given that the supposed justification for hyper-modernism is "optimization".
Comment: @kchoi: At minimum, compilers should by default recognize certain patterns that indicate that aliasing is likely; if a `T*` is cast to a `U*`, for example, ensure that any operations on `T*` which precede the cast also precede any uses of the resulting `U*`, and any operations on `T*` that follow the cast also follow any uses of the resulting `U*` which occurs before them.  In some cases that would block what might otherwise have been useful optimizations, but it would be far more likely to make code work more cheaply than if the code had to use `char*` and the compiler had to...
Comment: @supercat No, modern C is the result of an incompetent re-design by people with no understanding of compiler design, optimization, or the formalism of a specification. It looks like a train crash.
Comment: @supercat It's a very unsettling conclusion.
Comment: ...consequently expect that the `U*` might alias anything, rather than only having to expect that within a certain range of code it might access a `T`.  I really doubt the authors of the C89 Standard would have taken seriously anyone who warned that unless they explicitly authorize such a pattern (using the cast pointer strictly between the next and subsequent access with the original type), compilers would optimize them out even on platforms where they would otherwise be useful, but unfortunately such obtuse behavior is now fashionable.
Comment: @curiousguy: Reading your last comments to me and slashmais I'm not quite clear what you're trying to say about which versions of C.  Perhaps we could discuss in a chat session?  Protocol specifications make key distinctions which are missing in the C standard with regard to what compilers must provide vs what programs may legitimately rely upon, and between things implementations may do if convenient, things they should do if at all practical, and things they must do to be regarded as compliant  On the other hand, C was written I think before such specs became common.
Comment: @curiousguy What I think slashmais might have been talking about is: (1) When a function takes multiple pointers that are not supposed to overlap, they should be explicitly declared as `restrict`; not doing so is a bad habit and should be "punished" by bad machine-code efficiency (as is already happening when the pointers happen to have the same type). (2) There are certainly examples of undefined behaviors, such as out-of-bound array access, that are more well-known than aliasing problems.
Answer: As addendum to what Doug T. already wrote, here
is a simple test case which probably triggers it with gcc :
check.c
#include <stdio.h>

void check(short *h,long *k)
{
    *h=5;
    *k=6;
    if (*h == 5)
        printf("strict aliasing problem\n");
}

int main(void)
{
    long      k[1];
    check((short *)k,k);
    return 0;
}

Compile with gcc -O2 -o check check.c .
Usually (with most gcc versions I tried) this outputs "strict aliasing problem", because the compiler assumes that "h" cannot be the same address as "k" in the "check" function. Because of that the compiler optimizes the if (*h == 5) away and always calls the printf.
For those who are interested here is the x64 assembler code, produced by gcc 4.6.3, running on ubuntu 12.04.2 for x64:
movw    $5, (%rdi)
movq    $6, (%rsi)
movl    $.LC0, %edi
jmp puts

So the if condition is completely gone from the assembler code.
Comment: To make things more fun, use pointers to types which aren't compatible but have the same size and representation (on some systems that's true of e.g. `long long*` and `int64_t`*).  One might expect that a sane compiler should recognize that a `long long*` and `int64_t*` could access the same storage if they're stored identically, but such treatment is no longer fashionable.
Comment: Grr... x64 is a Microsoft convention. Use amd64 or x86_64 instead.
Comment: if you add a second short * j to check() and use it ( *j = 7 ) then optimization disapear since ggc does not not if h and j are not actualy point to same value. yes optimisation is really smart.
Answer: According to the C89 rationale, the authors of the Standard did not want to require that compilers given code like:
int x;
int test(double *p)
{
  x=5;
  *p = 1.0;
  return x;
}

should be required to reload the value of x between the assignment and return statement so as to allow for the possibility that p might point to x, and the assignment to *p might consequently alter the value of x.  The notion that a compiler should be entitled to presume that there won't be aliasing in situations like the above was non-controversial.
Unfortunately, the authors of the C89 wrote their rule in a way that, if read literally, would make even the following function invoke Undefined Behavior:
void test(void)
{
  struct S {int x;} s;
  s.x = 1;
}

because it uses an lvalue of type int to access an object of type struct S, and int is not among the types that may be used accessing a struct S.  Because it would be absurd to treat all use of non-character-type members of structs and unions as Undefined Behavior, almost everyone recognizes that there are at least some circumstances where an lvalue of one type may be used to access an object of another type.  Unfortunately, the C Standards Committee has failed to define what those circumstances are.
Much of the problem is a result of Defect Report #028, which asked about the behavior of a program like:
int test(int *ip, double *dp)
{
  *ip = 1;
  *dp = 1.23;
  return *ip;
}
int test2(void)
{
  union U { int i; double d; } u;
  return test(&u.i, &u.d);
}

Defect Report #28 states that the program invokes Undefined Behavior because the action of writing a union member of type "double" and reading one of type "int" invokes Implementation-Defined behavior.  Such reasoning is nonsensical, but forms the basis for the Effective Type rules which needlessly complicate the language while doing nothing to address the original problem.
The best way to resolve the original problem would probably be to treat the
footnote about the purpose of the rule as though it were normative, and made
the rule unenforceable except in cases which actually involve conflicting accesses using aliases.  Given something like:
 void inc_int(int *p) { *p = 3; }
 int test(void)
 {
   int *p;
   struct S { int x; } s;
   s.x = 1;
   p = &s.x;
   inc_int(p);
   return s.x;
 }

There's no conflict within inc_int because all accesses to the storage accessed through *p are done with an lvalue of type int, and there's no conflict in test because p is visibly derived from a struct S, and by the next time s is used, all accesses to that storage that will ever be made through p will have already happened.
If the code were changed slightly...
 void inc_int(int *p) { *p = 3; }
 int test(void)
 {
   int *p;
   struct S { int x; } s;
   p = &s.x;
   s.x = 1;  //  !!*!!
   *p += 1;
   return s.x;
 }

Here, there is an aliasing conflict between p and the access to s.x on the marked line because at that point in execution another reference exists that will be used to access the same storage.
Had Defect Report 028 said the original example invoked UB because of the overlap between the creation and use of the two pointers, that would have made things a lot more clear without having to add "Effective Types" or other such complexity.
Comment: @jrh: I think it would be pretty simple.  Recognize that 1. For aliasing to occur during a particular execution of a function or loop, two different pointers or lvalues must be used *during that execution* to address the same storage in conflicting fashon; 2. Recognize that in contexts where one pointer or lvalue is freshly visibly derived from another, an access to the second is an access to the first; 3. Recognize that the rule is not intended to apply in cases that don't actually involve aliasing.
Comment: The exact circumstances where a compiler recognizes a freshly-derived lvalue may be a Quality-of-Implementation issue, but any remotely-decent compiler should be able to recognize forms that gcc and clang deliberately ignore.
Comment: Well put, it would be interesting to read a proposal of sorts that was more or less "what the standards committee could have done" that achieved their goals without introducing as much complexity.
Comment: The `s.x = 1;` example is not UB, because a struct type is compatible with the type of its first field. The object `s` stores both an `int` AND a `struct S`.
Comment: @yyny: Both examples contain `s.x = 1;`, so I'm not clear which one you're talking about.  If `p1` and `pp2` are pointers to different structure types that start with an `int[5];`, gcc won't recognize the possibility that a write to `*(pp2->x)` might affect the value of `p1->x[i]`, even though both are lvalues of type `int`.  See https://godbolt.org/z/3xdqKjsMe for an example.
Comment: @supercat I am not talking about a particular one, ALL assignments to `s.x = 1;` are well defined by the standard. You said "the authors of the C89 wrote their rule in a way that, if read literally, would make [`s.x = 1`] UB", but that is not true.

Your Godbolt example uses two structs, different struct types are never compatible, even if they have compatible fields. When you access `p1` and `p2` as different types, the compiler is allowed to assume they don't alias. That is the definition of the strict aliasing rule.
Comment: @yyny: In the second code sample, the type of lvalue `s.x` is `int`.  The list of lvalue types that may be used to access the stored value of a `struct S` includes `struct S`, other aggregates that contain `struct S` as a member, character types, and qualified versions of the above.  In order for `s.x=1;` to have defined behavior, either the type of `s.x` would have to be something other than `int`, the list of allowable lvalue types for `struct S` would need to contain `int`, or the assignment would have to not access the storage associated with a `struct S`.  Which condition applies?
Comment: @yyny: The only way to have the "strict aliasing rule" not completely break the language is to interpret some words as having meanings that are inconsistent with their usage elsewhere in the Standard, in which case the question of what is or is not defined will depend upon how one fudges the meanings of the words involved.
Comment: When you execute `s.x = 1;`, you are accessing BOTH. First, you access the `struct S` object `s` to obtain the `int` object `s.x`, and then you access the `int` object `s.x` to assign it the value `1`. I did make an inaccuracy, I said that a struct is "compatible" with its first field, but that is not true in the way the standard defines it (Actually, you can even observe that in Godbolt with `*(int*)&p2 = 2;`). But my main point was that `s` contains both a `struct S` object as well as an `int` object. `s.x = 1;` is still well-defined.
Comment: @yyny: Does "accessing the struct S object" mean reading it or writing it?  The term "access" is limited to those two things.  Even if one munges the definition of "access" to allow that, trying to access an array within a structure would still fail because `s.intArrayMember[x] = 1;` would be defined as taking the address of `s.intArrayMember` (an operation that definitely doesn't read nor write `s`), displacing it by `x` times the size of the element type bytes, and then writing an `int` to that address.
Comment: @yyny: If one interprets the requirements as saying not that an lvalue must be of suitable type, but rather that it must be freshly visibly derived from something of suitable type, then constructs like those described would pose no problem, and if compilers spent as much effort looking for evidence of fresh visible relationship as they spend looking for opportunities to exploit their absence, many constructs clang and gcc don't support without `-fno-strict-aliasing` would work just fine even without that flag.
Answer: Type punning via pointer casts (as opposed to using a union) is a major example of breaking strict aliasing.
Comment: See my [answer here for the relevant quotes, especially the footnotes](http://stackoverflow.com/a/20956250/1708801) but type punning through unions has always been allowed in C although it was poorly worded at first. You my want to clarify your answer.
Comment: @ShafikYaghmour: C89 clearly allowed implementers to select the cases in which they would or would not usefully recognize type punning through unions.  An implementation could, for example, specify that for a write to one type followed by a read of another to be recognized as type punning, if the programmer did either of the following *between the write and the read*: (1) evaluate an lvalue containing the union type [taking the address of a member would qualify, if done at the right point in the sequence]; (2) convert a pointer to one type into a pointer to the other, and access via that ptr.
Comment: @ShafikYaghmour: An implementation could also specify e.g. that type punning between integer and floating-point values would only work reliably if code executed an `fpsync()` directive between writing as fp and reading as int or vice versa [on implementations with separate integer and FPU pipelines and caches, such a directive might be expensive, but not as costly as having the compiler perform such synchronization on every union access].  Or an implementation could specify that the resulting value will never be usable except in circumstances using Common Initial Sequences.
Comment: @ShafikYaghmour: Under C89, implementations *could* forbid most forms of type punning, including via unions, but the equivalence between pointers to unions and pointers to their members implied that type punning was allowed in implementations that didn't *expressly* forbid it.
Answer: After reading many of the answers, I feel the need to add something:
Strict aliasing (which I'll describe in a bit) is important because:

Memory access can be expensive (performance wise), which is why data is manipulated in CPU registers before being written back to the physical memory.
If data in two different CPU registers will be written to the same memory space, we can't predict which data will "survive" when we code in C.
In assembly, where we code the loading and unloading of CPU registers manually, we will know which data remains intact. But C (thankfully) abstracts this detail away.

Since two pointers can point to the same location in the memory, this could result in complex code that handles possible collisions.
This extra code is slow and hurts performance since it performs extra memory read / write operations which are both slower and (possibly) unnecessary.
The Strict aliasing rule allows us to avoid redundant machine code in cases in which it should be safe to assume that two pointers don't point to the same memory block (see also the restrict keyword).
The Strict aliasing states it's safe to assume that pointers to different types point to different locations in the memory.
If a compiler notices that two pointers point to different types (for example, an int * and a float *), it will assume the memory address is different and it will not protect against memory address collisions, resulting in faster machine code.
For example:
Lets assume the following function:
void merge_two_ints(int *a, int *b) {
  *b += *a;
  *a += *b;
}

In order to handle the case in which a == b (both pointers point to the same memory), we need to order and test the way we load data from the memory to the CPU registers, so the code might end up like this:

load a and b from memory.
add a to b.
save b and reload a.
(save from CPU register to the memory and load from the memory to the CPU register).
add b to a.
save a (from the CPU register) to the memory.

Step 3 is very slow because it needs to access the physical memory. However, it's required to protect against instances where a and b point to the same memory address.
Strict aliasing would allow us to prevent this by telling the compiler that these memory addresses are distinctly different (which, in this case, will allow even further optimization which can't be performed if the pointers share a memory address).

This can be told to the compiler in two ways, by using different types to point to. i.e.:
void merge_two_numbers(int *a, long *b) {...}

Using the restrict keyword. i.e.:
void merge_two_ints(int * restrict a, int * restrict b) {...}

Now, by satisfying the Strict Aliasing rule, step 3 can be avoided and the code will run significantly faster.
In fact, by adding the restrict keyword, the whole function could be optimized to:

load a and b from memory.
add a to b.
save result both to a and to b.

This optimization couldn't have been done before, because of the possible collision (where a and b would be tripled instead of doubled).
Comment: @NeilB - Yap you're right. We're only saving `b` (not reloading it) and reloading `a`. I hope it's clearer now.
Comment: Type-based aliasing may have offered some benefits prior to `restrict`, but I would think that the latter would in most circumstances be more effective, and loosening some constraints on `register` would allow it to fill in some of the cases where `restrict` wouldn't help.  I'm not sure it was ever "important" to treat the Standard as fully describing all cases where programmers should expect compilers to recognize evidence of aliasing, rather than merely describing places where compilers must presume aliasing *even when no particular evidence of it exists*.
Comment: Note that although loading from main RAM is very slow (and can stall the CPU core for a long time if following operations depend on the result), loading from L1 cache is pretty fast, and so is writing to a cache line that was recently writing to by the same core. So all but the first read or write to an address will usually be reasonably fast: the difference between reg/mem addr access is smaller than the difference between cached/uncached mem addr.
Comment: with restrict keyword, at step 3, shouldn't it be save result to 'b' only?  It sounds as if the result of the summation will be stored in 'a' as well.  Does it 'b' need to be reloaded again?
Comment: @curiousguy - although you're correct, "fast" in this case is relative. The L1 cache is probably still an order of magnitude slower than CPU registers (I think more than 10 times slower). In addition, the `restrict` keyword minimizes not only the speed of the operations but their number as well, which could be meaningful... I mean, after all, the fastest operation is no operation at all :)
Answer: Strict aliasing is not allowing different pointer types to the same data.
This article should help you understand the issue in full detail.
Comment: You can alias between references and between a reference and a pointer as well.  See my tutorial http://dbp-consulting.com/tutorials/StrictAliasing.html
Comment: It is permitted to have different pointer types to the same data. Where strict aliasing comes in is when the same memory location is written through one pointer type and read through another.  Also, some different types are permitted (e.g. `int` and a struct which contains an `int`).
Answer: Technically in C++, the strict aliasing rule is probably never applicable.
Note the definition of indirection (* operator):

The unary * operator performs indirection: the expression to which it
  is applied shall be a pointer to an object type, or a pointer to a
  function type and the result is an lvalue referring to the object or
  function to which the expression points.

Also from the definition of glvalue

A glvalue is an expression whose evaluation determines the identity of
  an object, (...snip)

So in any well defined program trace, a glvalue refers to an object. So the so called strict aliasing rule doesn't apply, ever. This may not be what the designers wanted.
Comment: The C Standard uses the term "object" to refer to a number of different concepts.  Among them, a sequence of bytes that are exclusively allocated to some purpose, a not-necessarily-exclusive reference to a sequence of bytes to/from which a value of a particular type *could be* written or read, or such a reference that *actually* has been or will be accessed in some context.  I don't think there's any sensible way to define the term "Object" that would be consistent with all the way the Standard uses it.
Comment: @supercat Incorrect. Despite your imagination, it is actually fairly consistent. In ISO C it is defined as "region of data storage in the execution environment, the contents of which can represent values". In ISO C++ there is a similar definition. Your comment is even more irrelevant than the answer because all you mentioned are ways of _representation_ to refer objects' _content_, while the answer illustrates the C++ concept (glvalue) of a kind of expressions that tightly relates to the _identity_ of objects. And all aliasing rules are basically relevant to the identity but not the content.
Comment: @FrankHB: If one declares `int foo;`, what is accessed by the lvalue expression `*(char*)&foo`?  Is that an object of type `char`?  Does that object come into existence at the same time as `foo`?  Would writing to `foo` change the stored value of that aforementioned object of type `char`?  If so, is there any rule that would allow the stored value of an object of type `char` to be accessed using an lvalue of type `int`?
Comment: sizeof(int) is 4, does the declaration `int i;` create four objects of each character type `in addition to one of type `int`?  I see no way to apply a consistent definition of "object" which would allow for operations on both `*(char*)&i` and `i`.  Finally, there's nothing in the Standard that allows even a `volatile`-qualified pointer to access hardware registers that don't meet the definition of "object".
Comment: @FrankHB: In the absence of 6.5p7, one could simply say that every region of storage simultaneously contains all objects of every type that could fit in that region of storage, and that accessing that region of storage simultaneously accesses all of them.  Interpreting in such fashion the use of the term "object" in 6.5p7, however, would forbid doing much of anything with non-character-type lvalues, which would clearly be an absurd result and totally defeat the purpose of the rule.  Further, the concept of "object" used everywhere other than 6.5p6 has a static compile-time type, but...
Comment: ...6.5p6 adds a notion of "Effective Type" whose corner cases are very badly broken, ambiguous, and unworkable.  Bizarrely, even though the "Effective Type" notion of 6.5p6 is clearly based upon the stated rationale for Defect Report #028, whose authors said that because writing one union member and reading another is Implementation-Defined behavior, using a pointer to do so is Undefined Behavior, the rule as written fails to actually handle the corner case described in Defect Report #028.
Comment: @FrankHB: Also, on a platform where a write to e.g. `GPIOA->BSSR = x;` would atomically behave in a fashion equivalent to `GPIOA->ODR = GPIOA->ODR | (x & 0xFFFF) & ~(x>>16);`, but reads of `GPIOA->BSSR` always yield zero, would `GPIOA->BSSR` be an "object" given that values written to its upper bits aren't actually stored anyplace, or would an attempt to write `GPIOA->BSSR` be Undefined Behavior on the basis that `GPIOA->BSSR` isn't an object?
Comment: @supercat In C, an lvalue (as an expression) always has a statically determined type. That type is used in the access to the object it referred to, and there is no way to simultaneously access "all of them" even before taking 6.5p7 into account. I fail to see how it "defeat the purpose of the rule". (And to be clear, which rule, exactly?)
Comment: DR 028 is about the dynamically determined type of objects not explicitly introduced by declarations. This is not the case of union members which are declared, even though they are not _created_ upon their declarations.
Comment: ...  I agree the notion of _effective type_ does not handle the lifetime issues well (as C++'s _dynamic type_), but the purpose of the notion is simply not for the union members. So, don't expect it will reproduce the exact same restrictions as the accesses on union members.
Comment: @supercat An object designating an register is usually needed to be qualified by `volatile`. The additional value adjustment is virtually the access from the external environment, if necessary. It won't be undefined just because of not being an object introduced by a declaration (although the declaration to introduce such volatile lvalues can not be strictly conforming).
Comment: If an implementation given `int foo{float *fp, int *ip) { if (*ip) *fp = 1.0; return *ip;}`, if an implementation were required to handle the case where `fp` and `ip` identified items in the same union, the code required to do so would be completely independent of the type of union involved, so the semantics need not be affected by what kind of union might exist, or whether any union in fact existed.  The purpose of DR #028 was to say that such handling wasn't necessary, but the stated rationale was completely nonsensical.  Also, I'm interested in your answer to the first question: if...

What is the strict aliasing rule?


what happens to spent bitcoins gained from a block of a soon to be dropped chain as a result of a fork?

Question: lets say i gained bitcoins for mining a block and then spent them on a transaction, then later the chain im using gets replaced because of a longer chain. assuming the block difference is up to where i got my spent bitcoins, what will happen to the transactions and coins i gained and spent from mining in my dropped chain?
Answer: all coinbase transactions are timelocked from when they are mined, so they are not spendable for a few days i believe. by that time, the block is near impossible to reverse and you can spend the new coins.
Comment: Correct, they are not mature until 100 blocks have been mined on top


Sign up page guidelines or trend?

Question: Is there a reason why the signup page on many websites are totally separated from the rest? I noticed that it results as a single page, where there is only the logo of the site and the signup form. No footer, no links, no header etc. The page seems to be totally separated from the rest of the site. I think that it could depends on the fact that users must not go away from this page, but I'm wondering how can I go back and return to the home page?Some sites (es. Linkedin) don't allow you to go back, and you have to rely on browser back button. What do you think about it?Is it a UX guidelines or just a "trend"?
Comment: I think I haven't found a site with such a bare bones sign up page, I don't use linkedin, but in most cases I'd say it is a design mistake, at least the home link should be there. I'd say that is a bad UX.
Answer: In addition to all of the previous answers, another factor for the independent sign-up page is that there may be some referral data at play. A great deal of services want to know where a user was linked from – be it Twitter, Facebook or some other site – in order to measure the impact of their advertising efforts or influence. Additionally, there may also be some sort of bonus  involved for the referrer or end user. For instance, if I send someone to my webhosts' sign-up page with a specific string appended to the URL, they get a discount and I can get a sign-up bonus. Allowing the user to access the site outside of that page prevents this type of deal from working.
However, I don't think that completely disconnecting the end user from the rest of the site is that great of an idea. I would rather take the risk of not getting 100% accurate analytics data or missing out on a discount here or there than to allow for the perception of my service being untrustworthy or poorly architected.
Answer: If a user is directed to a sign up page then the only thing available for the user must be to sign up. When it comes to user experience the user must get what he/she is looking for and what he/she has come there for. Keeping other options/ information on the page may not only be less productive but may also host as a distraction for the visiting user. Hence the standalone page for it. This decision may be based on the changing rather evolving UX trends. However there may be guidelines that govern it that I am unaware of.
However there must be some kind of navigation option on the page that may help the user to exit the page without having the leave the site/ application. Unless it is the requirement of the site that the user has to be a member to view anything this kind of approach may be avoided, since if a user changes his/her mind of signin up and wants to browse through the content then it should be possible without having to exit the site and browsing back to it. Else that will be a dead end and the navigation of the site will be incomplete.
Comment: I agree that there must be some kind of navigation option to help user to exit the page without having to leave the site. But do you think that only the logo (which leads to the home page) is enough or there must be a link like go to home/other pages?
Comment: Now a days most of the users are using logo to go back to home.  And others links policy, privacy, etc. should be there.
Comment: As far as going to the home page is concerned the logo would be the most intuitive option. Where as for other pages I believe we can let the user go to the home page since that will already have the reference to all the pages so why make you sitemap unnecessarily complex by taking them via the sign up page. Logically when a user is at the sign up page either he wants to proceed or go back to the home page if he changes his mind, so it will be safe if we rule out the rest of the options.
Answer: Here I'm giving a try- there are many dependencies the service provider would validate while anyone sign up for them.
1. Correct information
2. Security
3. Avoiding spam
From user experience point of view during signup, user has to depend upon his cognitive load.  they have to recollect many things and also try different options.  So to reduce this load, sign up page will be made as simple as possible.
Now a days, in many signup page, they are not asking to fill the form, instead user information is taken from different trusted sites which user has already a part of it.  In this way, user also doesn't required to maintain different mail ids also websites too doesn't need too either.
Coming to your question about why there is no provision to go back to the main page, may be because they want to avoid spams as I mentioned above.  And user to focus on this part itself.
May not be relevant but helpful insights
http://janrain.com/blog/social-login-trends-across-web-q4-2013/
Answer: In addition to the reduction to cognitive load -
It might sometimes be a technical limitation. Many sites take you to completely different area as that separated area might be run by a completely third party site. Contests and Loyalty on some Publisher properties can run this way.
That may partially answer the back button dilemma.
The other half is perhaps to prevent double entry (if the user decides to refresh the page, or go back and then forward again.)
There is also the risk that if the user goes back and then forward again, they could lose the data they already typed in.

Sign up page guidelines or trend?


Can an American Citizen Transit in USA with Expired US Passport

Question: My son is a dual citizen of the UK and USA. His US passport has expired. However, his UK passport is still valid. We are flying from the UK to Mexico via Atlanta. Will he be allowed to transit in Atlanta with an expired US passport?
Comment: "it shall be unlawful for any citizen of the United States to depart from or enter, or attempt to depart from or enter, the United States unless he bears a valid United States passport."  Transit implies both entry and departure.
Comment: Also note that immigration does acknowledge the possibility that a dual citizen might travel on a non-US passport: "If you have a true emergency, and are unable to obtain a U.S. Passport before your travels and have only a VWP-eligible country's passport, then you will have to file with ESTA to use that passport to travel to the U.S., and you will have to use the non-resident queue when arriving at the U.S. airport using the foreign passport." (source: https://help.cbp.gov/app/answers/detail/a_id/1096/~/esta---eligible-passport,-country-of-issuance,-citizenship)
Comment: It's worth nothing that the ESTA work-around page cited above has now disappeared.
Answer: You really don't want to try this.
The US consulate will tell you nothing other than that it is unlawful to enter or exit the US with an expired US passport. And this is true. However, it's a law with no teeth as there's no defined penalty. Its only real practical effect is that since it is a law, air carriers must follow it, and so they will refuse to board someone flying to the US on an expired US passport (which means you'll have to show your airline the other passport and an ESTA).
However, the US can't deny you entry if you can prove you're a US citizen, and an expired US passport is sufficient for this.
What happens in practice if you show up at the US border with an expired US passport is: You may go to secondary screening. You may be detained for some time while your identity and documents are verified. This might take two minutes or it could take hours if they have to call someone in (e.g. if they want a document specialist to examine the passport because it's damaged in some way). But you'll eventually be let in after being given a very stern talking-to and a piece of paper giving the list of acceptable documents for crossing the US border. (I have one of these pieces of paper around here somewhere...)
In other words, unless you have a really long layover, count on missing your outbound flight.
If at all possible, you should renew the passport before your trip. The US embassy and consulates in the UK can provide same-day emergency passport service if your travel is within 5 days, and regular passport renewal generally within 4 weeks. This will cost you some money, but it will pretty much eliminate the possibility of inconvenience at the US border.
If that's not possible, and your layover is long enough, you may be able to squeeze in a visit to the passport office in Atlanta and get a same-day renewal. Appointments are required though, so you might not be able to do this.
Comment: One of the ESTA questions is "are you a citizen of any other country?" and requests details. If you applied through ESTA and indicated you're a US Citizen, I don't really know what would happen. Perhaps they'd deny you and tell you to get a US passport?
Comment: @DJClayworth Hm. I'm pretty sure I saw that question asked here before...
Comment: What if the OP took the alternate strategy, simply showed his UK passport at US immigration, and said nothing about the US passport unless directly asked?
Comment: @DJClayworth: They would need to get an ESTA first before they can use the Visa Waiver Program, and the airline is supposed to check it
Comment: Forgot about ESTA.
Answer: Unfortunately Atlanta has no concept of international transit so you must clear immigration and and customs on arrival from the UK. See http://www.atlanta-airport.com/internationalterminal/passenger/types.html. As a US citizen your son is required to enter and exit the US with his US passport. You could try to do it all on the UK passport but it will be scanned and recorded. These days the Department of Homeland Security is better at data gathering and there is a chance that they will find out.
You can certainly enter Mexico with the UK passport. No visa required and perfectly legal. Getting into the US, however, would be tricky.
Best shots would be to get the US passport renewed or chose a flight that doesn't transit in the US.


Where do Master Limited Partnerships (MLP) lie on the risk/yield spectrum?

Question: MLPs are required to pay profits to their limited partners. Dividend stocks can choose to stop paying dividends. Corporate bonds payments are fixed interest (a set number) but MLP payments are usually a percent of profits (a variable number). Would MLPs be between corporate bonds and dividend stocks on the risk/yield spectrum? Safer than dividends, riskier than corporate bonds. Higher yield than bonds, less yield than dividends.
Answer: On the contrary, MLPs have actually performed worse then dividend stocks in recent years. Yes their payouts (as a percentage of cash flows) are guaranteed, but remember that the value of stocks/units includes not only the dividend payout but also the value of the underlying company.  A dividend payout is essentially cashing out a portion of the company and giving it to the shareholders, which means that the company CANNOT use it to grow, or worse, to weather bad financial times.
Non-MLPs can suspend dividends if necessary to retain cash to stay alive, while MLPs typically cannot. If an MLP hits a rough patch, they need to raise money somehow (usually by borrowing money), which may make them worse off financially than if they were able to suspend the dividend.
As an example, as oil/gas production dried up in 2014 the revenues of many pipeline MLPs plummeted (since they were's transporting nearly as much product).
Comment: are MLP payments always or usually a % of profits instead of a fixed absolute value? because if the payments are fixed wouldn't it not matter if the company does poorly? except for the cases of if the company goes bankrupt or you want to sell your LP units for a high price. but i'm assuming that you buy MLPs mostly for the payments and not for hoping to sell it at a higher price in the future.
Comment: They're typically a percentage of _cash flow_ (not necessarily income), but even so, my point is that the MLP _can't_ suspend dividends, which is a viable option for a non-MLP.
Comment: makes sense. another question. from wiki, the US requires that MLPs "must earn at least 90% of its gross income from qualifying sources, which were strictly defined as the transportation, processing, storage, and production of natural resources and minerals." i've read online that this effectively constrains MLPs to industries with very stable incomes/cash flows which i assume means they don't need much capital for growth. wouldn't that make being unable to stop payments less important?
Comment: That's the _hope_, but as oil/gas production dried up in 2014 the revenues of many pipeline MLPs plummeted (since they were's transporting nearly as much product). And they still need cash to grow so they can service more areas.
Comment: cool. this seems to be a satisfactory answer. i read that you shouldn't pick an accepted question on stackexchange too quickly so I guess i'll wait a little first? also a suggestion now that the answer is complete is putting the explanations from the discussion into your main answer so people don't have to read the discussion.


Settings for CuraEngine

Question: What is the proper way to give printer settings to CuraEngine? Is it possible to put all these settings into a file (like Json formatted)?
CuraEngine.exe -v -o "c:\3d\test.gcode" "c:\3d\test.stl"

Answer: I think the easiest thing is to use the Cura application together with CuraEngine.
If your printer is not supported, you'll need to add it manually by adding a JSON here: https://github.com/Ultimaker/Cura/tree/master/resources/machines
But when you are done you can easily choose all the features you want. For example: generating supports, printing order when printing multiple models, etc.
Cura and CuraEngine are developed at the same time, so you can expect that all features supported by the engine are accessible by the UI.
Answer: I'm not sure if it's possible, but on github is code for setting CuraEngine up. Maybe you'll find this link,  CuraEngine/src/settings/settings.cpp helpful.
The latest release has more speed customization. You can change first layer speed, outer shell speed, inner shell speed, infill speed, and top and bottom speed.
You can cut objects, its just a little wonky. In the advanced tab there is a "cut off object at Z height" that you can use to cut objects in half.
Theoretically, you can put all settings into a JSON formatted file.
Answer: First, try
CuraEngine.exe --help

The proper way is to first load in settings from the .def.json file of your printer. However, the formulae in the machine definition file are not being processed. CuraEngine only uses the default_value.
Then you specify setting overrides to set specific settings to a specific value. The specified settings are applied to the last provided object/extruder and otherwise globally.
CuraEngine.exe -v -j machine.def.json -s global_setting=global_value
    -e1 -s setting=extruder_value
    -l object_to_be_printed_with_second_extruder.stl -s setting=object_value
    -o output.gcode

One-at-a-time mode is done by adding --next commands between each group:
CuraEngine [general settings] -g [settings for the first model] --next [settings for the next model]

Settings for CuraEngine