C and C++ Programming Questions

What is a pointer (embedded context)
A pointer is a variable that holds a memory address. In embedded systems pointers commonly reference RAM buffers, stack data, or memory-mapped peripheral registers (fixed physical addresses).

Declare & initialize

• Declaration: specify the type the pointer points to (controls dereference type/size).
• Initialization: assign address (variable, array, or constant address for MMIO).

int val = 42;           // normal variable
int *p = &val;          // p points to val
char buf[8];
char *bp = buf;         // bp points to buffer start
#define UART0_BASE ((volatile uint32_t *)0x40001000)
volatile uint32_t *uart = UART0_BASE; // MMIO pointer

Dereference & pointer arithmetic

• Dereference (*) reads/writes the object at the address.
• Arithmetic advances by sizeof(type).

*p = 100;               // write to val
int x = *p;             // read val

// Traversing buffer
for (int i = 0; i < 8; ++i) {
    bp[i] = i;          // equivalent to *(bp + i)
}

// MMIO example: write TX register at offset 0
uart[0] = 0x55;         // write 32-bit to UART data register

pointer-to-const vs const-pointer

• pointer-to-const: the pointed data is const (you cannot modify *p), pointer can change.

const char *p_to_const = buf; // *p_to_const is read-only; p_to_const = other allowed

• const-pointer: pointer itself is const (address fixed), you can modify pointed data.

char * const const_ptr = buf; // const_ptr cannot be reassigned; *const_ptr writable

• both const:

const char * const p_both = buf; // fixed address, read-only data

Notes for embedded

• Use volatile for MMIO: volatile prevents compiler optimizing away reads/writes.
• Use correct integer-width types and alignments (uint8_t *, uint32_t *) when accessing peripherals.

Example and problem
Consider code that casts between incompatible pointer types to access the same memory:

// UB: breaks under -O2 due to strict aliasing
void set_float_from_int(int *ip, float *fp) {
    *fp = 1.0f;
    *ip = 0x3f800000; // bit pattern for 1.0f
    // later read float
    float v = *fp; // optimizer may assume *fp wasn't changed by writing through int*
    (void)v;
}

With optimizations the compiler may assume writes through int* cannot affect float* (strict aliasing), so it can cache *fp and the final read may still return 1.0 instead of the bit-twiddled value — undefined behavior leads to surprising, incorrect results on embedded targets.

Why optimizer can assume this
C's strict aliasing rule lets compilers assume objects are only accessed through compatible types (or char*). That allows aggressive reordering and caching of loads/stores for performance; the optimizer is correct only if the program conforms to the aliasing rules. Violating them yields UB so compilers are free to produce incorrect-seeming code.

Two correct fixes

1. Use memcpy (portable, safe, allows type-punning by copying bytes)

#include <string.h>
void set_float_from_int(int *ip, float *fp) {
    int i = 0x3f800000;
    memcpy(ip, &i, sizeof i);      // write int
    memcpy(fp, &i, sizeof *fp);   // reinterpret bits safely
}

2. Use uint32_t and char* (or unsigned char*) or use union carefully — preferred: unsigned integer + memcpy

#include <stdint.h>
#include <string.h>
void set_float_from_int(int *ip, float *fp) {
    uint32_t bits = 0x3f800000u;
    memcpy(ip, &bits, sizeof *ip);
    memcpy(fp, &bits, sizeof *fp);
}

Alternative: define and use a union for type-punning where your compiler documents support:

union { uint32_t u; float f; } u;
u.u = 0x3f800000u;
float v = u.f;

Takeaway for embedded developers
Never rely on pointer casts between incompatible types. Use memcpy or unsigned-char access (or well-documented unions) to be portable and correct under modern optimizing compilers. For debugging only, -fno-strict-aliasing can mask issues but is not a portable fix.

Brief explanation
Const-correctness for member functions means marking methods that do not modify observable object state with const. This enables safer APIs, allows calling on const objects, and helps compiler optimizations — important in embedded code where correctness and predictability matter.

Example class

#include <array>
#include <cstddef>

class SensorCache {
    std::array<int,4> readings_;
    mutable bool dirty_;           // cache metadata can change in const methods
public:
    SensorCache(): readings_{}, dirty_{true} {}

    // const getter: promises not to modify observable data
    int getReading(std::size_t i) const {
        if (i >= readings_.size()) return -1;
        // we might lazily refresh hardware status counter — allowed via mutable
        if (dirty_) {
            // update internal metadata only
            // e.g., increment diagnostics counter (not shown)
            // but do NOT modify readings_ here
            dirty_ = false;
        }
        return readings_[i];
    }

    // non-const updater: writes sensor values
    void updateReading(std::size_t i, int v) {
        if (i < readings_.size()) {
            readings_[i] = v;
            dirty_ = true;
        }
    }
};

mutable vs const_cast

• mutable marks non-observable members (counters, caches, locks) that may change inside const methods. Use it for debug counters, lazy-init flags, or synchronization primitives — safe and explicit.
• const_cast can remove const and write through it; this breaks the const contract, risks undefined behavior if the original object is truly const, and hides intent. In embedded systems this can cause subtle bugs and safety issues.

Prefer mutable for internal, well-documented state changes; avoid const_cast except when interfacing with legacy APIs and after careful justification.

Overview
Stack: LIFO, fixed per-task region set at link/startup; allocation/deallocation are single-instruction pointer moves (push/pop), deterministic and cheap.
Heap: dynamic, managed by malloc/free (or new/delete); allocation costs vary (search/split/coalesce), not deterministic and can be expensive on small CPUs.

Practical differences

• Allocation/deallocation cost
  • Stack: O(1) pointer adjust — predictable CPU cycles.
  • Heap: variable; can traverse free lists or manipulate boundary tags — unpredictable latency.
• Lifetime & ownership
  • Stack: scoped to function/thread; automatic lifetime, no explicit free.
  • Heap: programmer-controlled lifetime; risk of leaks if not freed.
• Fragmentation
  • Stack: no fragmentation within its region.
  • Heap: both internal/external fragmentation over time; severe on tiny RAM.
• Stack overflow risks
  • Stack grows into adjacent memory if overused (deep recursion, large locals, ISR nesting). On MCUs without MMU, overflow corrupts data or code, often silently.
• No MMU / limited RAM
  • No process isolation — heap corruption or stack overflow affect entire system. Dynamic allocation increases unpredictability.

When to prefer static/compile-time allocation

• Use static/global or compile-time sized objects for drivers, buffers, and RTOS tasks when sizes are known.
• Use fixed-size memory pools or ring buffers for dynamic-like behavior with bounded latency.

Concrete guidelines

1. Avoid general-purpose heap in hard real-time or deeply resource-limited firmware; prefer static allocation or fixed-size pools (pre-allocated buffers).
2. Analyze and enforce stack usage: set conservative per-task stacks in linker/RTOS, use compiler/stack-analyzer tools and runtime canaries to detect overflow.

Example: for a UART driver, allocate a static RX ring buffer and use a semaphore to signal processing task — no malloc required, deterministic behavior.

Direct answer (thesis)
Bitfields are convenient but not portable or always correct for hardware registers. Explicit masks+shifts give predictable, portable behavior across compilers, toolchains, and endiannesses.

Key issues

• Endianness & layout
  • C does not standardize bitfield ordering or whether they pack LSB/MSB first. Different compilers or ABIs can flip field order. Masks/shifts operate on integer semantics and are stable across endianness when you document register endianness and use fixed-width types (e.g., uint32_t).
• Packing & alignment
  • Compilers may insert padding between bitfield members or across struct boundaries. attribute((packed)) can reduce padding but may cause unaligned accesses or performance penalties on some targets. Masks avoid struct layout concerns.
• Atomicity & read-modify-write
  • Many hardware registers require atomic single accesses. A struct with bitfields can compile to multiple instructions: a read, modify, write sequence or even separate byte accesses. Masks+shifts let you control access size (e.g., use a single 32-bit write) and ensure volatile-qualified accesses.
• Volatile and compiler behavior
  • Volatile on bitfields is implementation-defined in some compilers; compilers may optimize or reorder accesses unexpectedly. Using volatile on the underlying integer and helper inline functions for read/write ensures defined behavior.
• Toolchain differences
  • Different compilers (GCC, Clang, IAR, Keil) implement bitfields differently (order, packing, code generation). Relying on bitfields ties you to a specific toolchain and ABI.

Practical recommendations

• Use explicit masks, shifts, and typed accessors for hardware registers:
  • Define positions and masks as constants.
  • Provide inline read-modify-write helpers that perform a single volatile-width access.
  • Example pattern: read = REG; read = (read & ~MASK) | ((val << POS) & MASK); REG = read;
• If you choose bitfields:
  • Only for non-hardware or when your toolchain/ABI guarantees layout and you have tests.
  • Add static assertions on sizeof(struct) and field offsets where supported.
• Test on real hardware and across toolchains; document assumptions (endianness, alignment, access width).

Using masks+shifts is slightly more verbose but safer and predictable for embedded hardware.