C and C Plus Plus Fundamentals Questions

Core syntax and semantics of C and C Plus Plus languages, including pointers, references, manual memory allocation and deallocation patterns such as malloc/free and new/delete, structs, enums, preprocessor directives, const and volatile qualifiers, function declarations and prototypes, and differences between C and C Plus Plus. Covers writing correct and idiomatic code, understanding undefined behavior, lifetime and ownership, common standard library usage, compilation and linking basics, and how language features affect correctness and performance.

MediumTechnical

63 practiced

You have legacy C code that violates the strict aliasing rule by type-punning via pointers. Explain the problem and show two correct alternatives in C to safely reinterpret a float as uint32_t and back without invoking undefined behavior.

Sample Answer

**Problem (brief)** Strict aliasing means the compiler may assume objects are only accessed through compatible types. Casting a float* to uint32_t* (type-punning via pointer) can invoke undefined behavior: the compiler may optimize away or reorder accesses, breaking correctness on optimized builds—bad for embedded firmware.

**Two correct alternatives**

1) Safe and portable: memcpy (recommended)- Uses byte-wise copy, no aliasing UB, works across compilers.

#include <stdint.h>
#include <string.h>

uint32_t float_to_u32(float f) {
    uint32_t u;
    memcpy(&u, &f, sizeof u); // copy representation
    return u;
}

float u32_to_float(uint32_t u) {
    float f;
    memcpy(&f, &u, sizeof f);
    return f;
}

2) Union-based (practical in embedded, widely supported but implementation-defined in strict standard terms)- Many compilers guarantee expected behavior and it's zero-cost; still check toolchain docs.

#include <stdint.h>

union pun {
    float f;
    uint32_t u;
};

uint32_t float_to_u32_union(float f) {
    union pun p;
    p.f = f;
    return p.u;
}

float u32_to_float_union(uint32_t u) {
    union pun p;
    p.u = u;
    return p.f;
}

**Notes / Embedded guidance**- Ensure sizeof(float) == 4 and endianness expectations (static_assert where available). - Prefer memcpy for strict portability and when certifiability (MISRA, safety) matters; union is common in low-level code for performance but verify your compiler behavior and optimization flags.

HardTechnical

72 practiced

Provide a concrete example where compiler optimizations combined with the strict aliasing rule lead to incorrect program behavior in C. Explain why the optimizer is allowed to assume strict aliasing, and show two correct ways to fix the code so it is portable and safe on modern compilers.

Sample Answer

**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.

EasyTechnical

125 practiced

In C, explain what a pointer is, how to declare and initialize pointers, and show an example of pointer dereference and pointer arithmetic. Also explain the difference between a pointer-to-const and a const-pointer, with short code examples. Frame the answer for embedded systems where pointers commonly reference memory-mapped registers and peripheral buffers.

Sample Answer

**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.

EasyTechnical

61 practiced

Explain scoped enums (enum class) in C++ and how they differ from C-style enums. Discuss underlying type selection, implicit conversions, and why enum class can reduce bugs in embedded code where integer sizes and sign matter.

Sample Answer

**Definition & key idea**Scoped enums (enum class) in C++ are strongly typed, scoped enumerations introduced in C++11. They put enumerator names inside the enum scope and prevent implicit conversions to integers, improving type-safety—very useful in embedded development where integer sizes and signedness matter.

**Example (contrast)**

cpp

// C-style
enum Mode { Off = 0, On = 1 };

// Scoped
enum class ModeSC : uint8_t { Off = 0, On = 1 };

**Differences**- Scope: Mode::Off vs global Off — scoped enums avoid name collisions.- Implicit conversions: C-style enums implicitly convert to int; enum class does NOT. You must use static_cast<int>(ModeSC::On).- Underlying type: C-style underlying type is implementation-defined (often int). enum class lets you specify exact underlying type (e.g., uint8_t), which controls size and signedness explicitly — critical for memory layout, registers, and ABI in embedded systems.

**Why enum class reduces bugs in embedded code**- Prevents accidental arithmetic or comparisons between unrelated enums and integers that can cause overflow or sign-misinterpretation.- Controls storage size and signedness so struct layouts and peripheral register mappings are predictable.- Reduces namespace collisions that can lead to wrong constant use.- Forces explicit casts, making intent visible in code reviews and preventing subtle implicit-conversion bugs.

**Practical tips**- Use enum class : uint8_t/uint16_t for packed tables or memory-mapped registers.- Provide helper functions or operator overloads (explicit and documented) for bitwise operations when needed.

HardTechnical

61 practiced

You encounter a hard fault on a bare-metal ARM Cortex-M device running C/C++ firmware. Describe a systematic debugging plan: what registers and stack frame to inspect, how to interpret fault status registers, how compiler optimization levels can change fault behavior, and practical instrumentation techniques to make fault reproduction and stacking diagnostics reliable in production devices.

Sample Answer

**Approach (quick)** Systematically capture the CPU state at the hard fault, interpret the fault status registers to find root cause, account for compiler optimizations that change crash location/stack layout, and add lightweight production instrumentation to reliably reproduce and diagnose.

**1) Inspect registers & stacked frame** - On exception entry Cortex‑M automatically pushes: R0, R1, R2, R3, R12, LR, PC, xPSR (either main or process stack). Recover these from the stack pointer (MSP/PSP depending on EXC_RETURN). - Check LR value (EXC_RETURN) to know whether stack uses PSP or MSP and whether interrupted code was in Thread/Handler mode. - Use stacked PC as the faulting instruction address; examine PC-2/PC-4 if Thumb/exception prefetch.

**2) Fault status registers to read** - SCB->HFSR (HardFault Status): bit 30 = FORCED (means another fault escalated). - SCB->CFSR (Configurable Fault Status): split into UFSR (UsageFault), BFSR (BusFault), MMFSR (MemManage). Read specific bits: UNALIGNED, DIVBYZERO, NOCP, INVPC, INVSTATE in UFSR; PRECISERR/IMPRECISERR, BFARVALID in BFSR; MMARVALID in MMFSR. - SCB->MMFAR / SCB->BFAR: valid when corresponding VALID bit set — gives faulting address for memory/bus faults. - Interpret sequence: if HFSR.FORCED set -> read CFSR to see underlying fault; check BFAR/MMFAR validity before trusting addresses.

**3) How compiler optimizations change behavior** - Optimizations can inline/omit functions, reorder loads/stores, make stack frames ephemeral and remove frame pointers — stacked PC may point at inlined call site or not match source line. - Some faults (use-after-free, race conditions, timing-sensitive) only appear at -O2/-Os because of register allocation or instruction scheduling. Conversely, -O0 may hide issues. - Use compilation flags during debug: -g -Og for meaningful debug info with optimizations; use -fno-omit-frame-pointer to preserve frame pointers; for GCC, -fno-strict-aliasing can help diagnose aliasing bugs.

**4) Practical instrumentation for production diagnostics** - Implement a robust HardFault_Handler that: - Captures stacked registers and SCB registers into a reserved RAM diagnostics structure (located in a no-init RAM section) so they survive resets. - Sets a persistent flag in battery-backed RAM/flash or EEPROM indicating fault occurred and pointer to saved frame. Use CRC. - Optionally transmit core dump via UART/USB/ITM/SWD if link present; keep payload minimal (R0-R3,R12,LR,PC,xPSR, CFSR,HFSR,MMFAR,BFAR,SP). - Use watchdog hold-off to allow dump; or on next boot, if diagnostics flag set, dump over network or log to non-volatile storage. - Lightweight tracing: enable ITM/SWO or GPIO toggles or cycle counters to capture execution path leading to fault; add periodic checkpoints with sequence numbers written to reserved RAM to narrow last known good location. - Add stack canary and check for overflow in faults where corruption suspected. - For intermittent faults, add link-time symbolization: store build-id and map on server to map PC->source.

**5) Practical debugging workflow** - Reproduce under debugger: break on HardFault, read stacked frame at SP, decode PC to source. If PC in libc/C startup, inspect EXC_RETURN and stack to find caller. - If CFSR shows MemManage/BusFault, examine BFAR/MMFAR and surrounding memory maps/peripherals (misconfigured MPU, invalid peripheral access). - If UsageFault (UNALIGNED, DIVBYZERO, NOCP, INVSTATE), inspect instruction at PC and compiler-generated code patterns. Try building with -O0 or -Og and frame pointers to get stable repro and stack traces. - Add assertions and boundary checks around suspicious code (null ptr checks, buffer bounds). Use address sanitizer equivalents (link-time instrumentation) where possible.

This plan yields deterministic capture of the minimal state needed to triage causes, accounts for optimizer-induced shifts in fault site, and provides low-overhead production diagnostics to avoid “Heisenbug” loss.

Unlock Full Question Bank

Get access to hundreds of C and C Plus Plus Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.