I think the most important point of Friendly C is not to define <i>the</i> behaviour for what would otherwise be undefined, but to define <i>a</i> behaviour; from this point of view, it would be unnecessary to argue over the examples he mentions like memcpy() vs memmove() and integer shifting --- it only suffices that every implementation define the behaviour, and what that behaviour precisely is can differ between them. A lot differs already between platforms, and so all this basically means is to document those differences. This agrees with the spirit of the language as a &quot;high level assembler&quot;, removes all the undefinedness, and would be entirely unsurprising to most programmers.<p><i>The situation gets worse when we start talking about a friendly semantics for races and OOB array accesses.</i><p>I don&#x27;t have anything to say about races, but OOB array accesses should simply do what you&#x27;d expect the hardware to do: attempt to access memory at the location the array indexing equation gives. It may segfault, or it may access some other contents in memory. That&#x27;s what any C programmer would probably expect.