C shennanigans.

This text focuses on some of the non-obvious and easy to make mistakes non-experienced C programmers are likely to make and are/can not completely be covered by tooling without going into edge cases relevant to performance:

Pointer semantics
Sequence points
Bit-fields

Compiler flags or implementation may provide workarounds to these problems to prevent optimizations based on introduced Unedefined Behavior (UB). Review used C compilers with flags used including tests and and platforms before reusing of any code. The SEI wiki covers these cases without covering compiler workarounds leading to footguns, if code is used by other compiler implementations or with different compiler flags and is more verbose on rules how pointers are allowed to be used.

Pointers semantics in C.
- Pointer access requirements.
  1. Proper alignment
  2. Sufficient storage (pointer must point to valid object)
  3. Sufficient padding (ie withing structs).
  4. Correct aliasing
    - "Strict Aliasing Rule"
      > 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.
      What this means in practice:
      Each pointer has an associated "provenance" it is allowed to point to. This mean that a pointer ptr must uphold (&array[0] <= ptr && ptr < &array[len+1]) || ptr != 0). for access with array being the "memory origin range" on stack or heap. Pointers must point ot the same array, when being used for arithmetic.
      Function arguments of identical pointer types are allowed to have overlapping provenance regions, unless annotated with __restrict__, but pointers of different types are not allowed to have those regions. Pointer comparison must be done via identical alignments, for example to compare a pointer against pointer to 0 (usually abbreviated via maro NULL).
- Pointer access in practice.
  - Provenance as regions pointer is allowed to point to for access.
    provenance.c
```
void use_ptr(int * ptr) {
  printf("0: %d, 9: %d\n", arr[0], arr[9]);
}
void main() {
  int arr1[10]
  use_ptr(arr1);
  int * arr2 = malloc(sizeof(int));
  use_ptr(arr2);
  free(arr2);
}
```
  - Copy around some bytes from not overlapping regions (otherwise use memmove).
    copy_bytes.c
```
void use_bytes(uint8_t * bytes, int32_t len_bytes, uint32_t * output, int32_t len_output) {
  for(int i=0; i*4<len_bytes && i<len_output; i+=4) {
    memcpy(&output[i], &bytes[4*i], sizeof(len_output));
  }
}
```
  - Correct alignment of pointers with temporary, when necessary.
    correct_alignment.c
```
int ptr_no_reinterpret_cast() {
  uint8_t arr[4] = {0,0,0,1};
  // unnecessary variable hopefully elided
  uint32_t u32_arr = 0;
  memcpy(&u32_arr, &arr[0], 4);
  uint32_t * u32_arr_ptr = &u32_arr;
  // <use u32_arr_ptr here>
  // Footgun: Dont return stack local variables
  return 0;
}
```
  - Ensure correct storage and padding size for pointers via sizeof.
    storage_padding.c
```
struct sStruct1 {
  uint8_t a1;
  uint8_t a2;
  uint32 b1;
  uint32 b2;
}
void padding() {
  struct sStruct1 * str1 = malloc(sizeof(sStruct1)); 
  str1.a1 = 5;
  free(str1);
}
```
  - Allowed aliasing of pointers
    allowed_aliasing.c
```
void allowed_aliasing(uint16_t * bytes, int32_t len_bytes, uint16_t * lim) {
  for(int i=0; i<len_bytes; i+=1) {
    if (bytes == lim) break;
    bytes[i] = 42;
  }
}
```
  - Non-Allowed aliasing of pointers: See example correct_alignment.c
- The Exceptions.
  - Controlling the build system + compiler invocation to opt-out.
    1. Clang and gcc have -fno-strict-aliasing, msvc and tcc do not implement strict aliasing based optimizations.
    2. Usage of restrict can be en/disabled in all compilers via #pragma optimize("", on/off).
  - Posix extension and Windows in practice enable dynamic linking via casting pointers void *to function pointers and back. This also means that sizeof (function pointer) == sizeof (void *) must be uphold, which is not true for microcontrollers with separate address space for code and data or CHERI in mixed capability mode/hybrid compilation mode. Address space annotations are mandatory for this to work and it is unfortunate that standards do not reflect this as of 20240428.
    aliasing_exceptions_uniform_address_space.c
```
void aliasing_exceptions_uniform_address_space() {
  typedef int(*pfn_add_one)(int);
  int add_one(int x) = { return x+1; } 
  void usage(int x) {
    // read fn ptr from external code
    void * pv_add_one = (void*)external_memory;
    pfn_add_one pfn_add_one_casted = (pfn_add_one)pv_add_one;
    int res = pfn_add_one_casted(1);
    assert(res == 1);
  }
}
```

Sequence Points in simple case and with storage lifetime extension.

sequence_points.c

int f(int* a) {
  *a=*a+1;
  return *a;
}
void simple_sequence_points() {
  int a = 0;
  // warning: Multiple unsequenced modifications to a
  // a = a++ + a++;
  // Problem without warnings
  a = f(&a) + f(&a);
  a = f(&a);
  a += f(&a);
}
struct sExample { int32_t a[1]; };
struct sExample create_sExample(void) {
  structt X res = { { 1 } };
  return res;
}
int storage_lifetime_footgun(void) {
  // undefined behavior introduced if temporary is missing
  // printf("%x", ++(create_fail().a[0]));
  struct sExample res = create_sExample();
  printf("%x", ++(res.a[0]));
  return 0;
}

Do not use bit-fields unless for non-portable code regarding compilers and CPUs and do not make assumptions regarding the layout of structures with bit-fields and use static_assert/_Static_assert on every struct. Keep bit-fields as simple as possible, meaning prefer not to nest them or also static_assert the layout.
Reasons from ISO/IEC 9899:TC3
> An implementation may allocate any addressable storage unit large enough to hold a bit
> field. If enough space remains, a bit-field that immediately follows another bit-field in a
> structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
> whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
> implementation-defined. The order of allocation of bit-fields within a unit (high-order to
> low-order or low-order to high-order) is implementation-defined. The alignment of the
> addressable storage unit is unspecified.
or in other words:
1. Order of allocation not specified.
2. Most significant bit not specified.
3. Alignment is not specified.
4. Implementations can determine, whether bit-fields cross a storage unit boundary.
5. Structs may contain padding bytes anywhere.