Document Number: N2484
Submitter: Aaron Peter Bachmann
Submission Date: 2020-02-19
Make pointer type casting useful without negatively impacting performance

Summary

Pointer-type-punning is useful but mostly undefined behavior according to the standards ISO/IEC 9899:1999 ... ISO/IEC 9899:2018.
Before that there were implementation defined aspects. Therefore we have to resort to additional - non-portable - extensions compiler normally provide or use another programming language (often assembler) or work-arounds to achieve our intended goals as programmers. Strict aliasing rules are also useful. They allow for more efficient code without extra work for the programmer. We can allow type-punning in many cases without negatively impacting performance.

Prior work

Why pointer casting is useful

• Operations on bigger objects are more efficient:

  • We want to have efficient implementations of memset(), memcpy(), strlen(), strcpy(), ...
  • The same applies for various checksums
• malloc() and friends shall be implementable in plain C
• The alternatives the standard provides often are a partial remedy only.
  

  • memcpy() is a canonical righteous way to deal with the representation of objects, but it has its problems
  • Sometimes compilers will not remove the memcpy() introduced. The programs become harder to read, the number of source lines increases, the programs become less efficient in terms of runtime, code-size, stack-consumption, latency.
  • memcpy() cannot reasonably be used in an implementation of memcpy().
  • Code placement issues arise: If a flash-programming routine uses memcpy(), then memcpy() must not reside in the same flash - often the only one. If code and data are both in RAM they may compete for the same bus introducing additional inefficiency.
  • Using unions for type-casting is safe, but can only be used to cast from one member-type of the union to another member-type of the union residing in the union-object. This is useful for example in code to implement software-floating-point but fails if we have to process objects with an incompatible type, e. g. an implementation of memcpy() which has to be able to copy objects of arbitrary type. 

Why strict aliasing rules are useful

• Strict aliasing rules allow for more efficient code without programmers intervention, i. e. without need to add restrict.
• The speedup is mostly for free.
• The risk of introducing new bugs is virtually non-existant, while exposing preexisting bugs is possible.

Prior art

• When C emerged, there were no strict aliasing-rules.
  
• Compilers (GCC, clang, icc, ...) allow to entirely disable the strict aliasing-rules e. g. via -fno-strict-aliasing. Some C-compilers assume no strict aliasing either by default or as the only option: pcc, tcc, the original C-compiler by DMR, Microsoft C-compilers, ...
• Major projects - e. g. Linux - heavily rely on -fno-strict-aliasing.
• More fine-grained control over aliasing is available in many existing compilers,  e. g. via attribute((__may_alias__))
  

Problem

Proposed solution

Make object-pointer-casting (casting a pointer-type to a pointer to a different  type)  valid and well defined in a local scope, i. e. function-scope and block-scopes within a function, provided that the value of the pointer derived from the original pointer via the cast to a fundamentally different pointer does not escape the scope. The accesses via this pointer shall be valid as well, provided we honor other restrictions (const, alignment, ...).

Discussion of the proposed solution and examples

• A cast introduced by a programmer explicitly expresses an intention. It does not happen accidently. The language and the compilers shall support the programmer. 
  
• In the absence of pointer-type casts, nothing changes with respect to the current standard. Thus, we have no slowdown.
  
• If the compiler cannot see the pointer-cast, nothing changes. For example the promise made by a function-prototype must remain valid for a well-defined program:
  

• An example - taken from musl-libc - modified for the proposal:
  

#include <string.h>
#include <limits.h>
#include <stdint.h>
#define ALIGN (sizeof(size_t))
#define ONES ((size_t)-1/UCHAR_MAX)          // 0x01010101 for 32 bit integer
#define HIGHS (ONES * (UCHAR_MAX/2+1))       // 0x80808080 for 32 bit integer
#define HASZERO(x) ((x)-ONES & ~(x) & HIGHS) // only 0 has OV & high bit 0

size_t strlen(const char *s){
    const char *a = s;
    const size_t *w;       
    for (; (uintptr_t)s % ALIGN; s++) if (!*s) return s-a;
    // harmless but undefined, because we eventually read more than object-size!
#ifdef STRLEN_USE_MEMCOPY
    // pray compiler will remove memcpy()   
    for (;memcpy(&w,s,sizeof(size_t)), !HASZERO(*w); s+=sizeof(size_t));
#else
    for (w = (const void *)s; !HASZERO(*w); w++); // code matching this proposal
    s = (const void *)w;
#endif
    for (; *s; s++);
    return s-a;
}


• Creating additional global, static or thread-local aliases remains invalid:

static float *Fp=(float*)&Something;

static unsigned *Uu=(unsigned*)&Something; // invalid

Proposed wording changes

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:⁸⁹⁾

• 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., or
• a properly aligned pointer of any object type that has been explicitly converted from a valid pointer of the effective object type as specified in 6.3.2.3.7 if the conversion is in a function-scope or a block-scope within a function-scope and if the pointer which underwent the conversion is only used within the scope.