Understanding `const` and Its Removal

The Great Danger: Modifying a const Object is Undefined Behavior

Let's be direct: if a variable is originally declared as const, any attempt to modify it—even after casting away the const qualifier—results in Undefined Behavior (UB).

In C, you can cast away const using a standard type cast:

const int a = 10;
int *p = (int *)&a; // Casting away const
*p = 20;            // Attempting to modify a const object -> UNDEFINED BEHAVIOR

This might seem to work sometimes, but it can fail in spectacular and non-obvious ways due to compiler optimizations. A const object might be placed in read-only memory, or the compiler might replace all reads of the variable with its initial value.

To see this in action, let's watch a short video that demonstrates the consequences. Although it uses C++'s const_cast, the underlying principle is identical in C.

Why Does This Happen? The "Assumed Absence of UB"

The behavior you just saw isn't a bug; it's a feature of high-performance compilers. Compilers operate on the principle of "assumed absence of undefined behavior." They assume your code is well-behaved and will never trigger UB. This assumption allows for powerful optimizations.

When you declare const int a = 10;, you give the compiler permission to:

1. Replace every use of a directly with the value 10.
2. Place a in a read-only data segment of the executable, which the operating system may protect from writes. Attempting to write to it would then cause a hardware fault (a segmentation fault on Linux or an access violation on Windows).

Casting away const and writing to *p violates the compiler's foundational assumption. Because the standard says the result is "undefined," the compiler is free to do anything—including producing code that appears to ignore your write completely.

The following video provides an excellent deep dive into how compilers exploit UB for optimization. Understanding this will fundamentally change how you view C code.

The "Legitimate" (But Still Risky) Use Cases

So, if modifying an originally const object is UB, is there ever a valid reason to cast away const? There is one, narrow, well-defined scenario, but it is often confused with a more common, illegitimate one.

Illegitimate Use Case: Interfacing with "Bad" APIs

The most common excuse for casting away const is to interface with a legacy or poorly designed function that fails to use const correctly in its parameters.

Imagine a library function:
void process_data(char *s1, size_t len);

The documentation swears that process_data only reads from s1. However, your code has a const char*.

const char* my_data = "Some important configuration string";
// process_data(my_data, strlen(my_data)); // This would cause a compiler warning/error.

The "quick fix" is to cast away const:
process_data((char*)my_data, strlen(my_data));

This is extremely risky.

• You are overriding a compile-time safety check based on a promise in the documentation.
• A future version of the library could change process_data to actually modify s1, and your code would silently break, possibly with UB if my_data points to a string literal in read-only memory.

The SEI CERT C standard explicitly warns against this. Failing to declare an unchanging parameter as const is a defect in the API, and casting to work around it is a violation of secure coding principles.

The proper solution is to fix the API to be const-correct. If that's not possible, this workaround should be heavily documented and understood as a significant source of technical debt and risk.

The Only Well-Defined Use Case

The C standard permits you to cast away const and modify the underlying object if and only if the original object was not declared const.

This sounds circular, so let's clarify with an example.

#include <stdio.h>

// This function only has a const "view" of the data
void try_to_modify(const int* p) {
    int* non_const_p = (int*)p; // Cast away const
    *non_const_p = 999;         // Is this UB? It depends!
}

int main() {
    // Case 1: Original object IS NOT const
    int x = 10;
    printf("Before: x = %d\n", x);
    try_to_modify(&x); // Perfectly valid and well-defined.
    printf("After: x = %d\n", x); // Will print 999

    // Case 2: Original object IS const
    const int y = 20;
    printf("Before: y = %d\n", y);
    try_to_modify(&y); // UNDEFINED BEHAVIOR
    printf("After: y = %d\n", y); // Could print 20, 999, or crash.

    return 0;
}

In Case 1, we start with a mutable int x. We pass its address to a function that receives it as a const int*. The const here is just a temporary, read-only "view." Inside the function, casting away that const view to modify the original, non-const x is perfectly legal.

In Case 2, we start with a const int y. When we try the same operation, we invoke UB because the object itself was immutable from its creation.

This well-defined use case is almost exclusively for situations where you have a non-const object but must pass it through a generic or intermediate API that (perhaps unnecessarily) applies a const view, before finally passing it to a function that needs write access.

// This function stores a pointer to a configuration block for later use.
// The pointer itself is stored in volatile memory, as an ISR might update it.
static const uint8_t* g_active_config = NULL;

void set_active_config(const uint8_t* config_block) {
    g_active_config = config_block;
}

void apply_calibration_offset(uint16_t offset) {
    if (g_active_config != NULL) {
        // A specific field at byte 4 needs to be updated with the offset.
        // This field is known to be a uint16_t.
        uint16_t* calibration_field = (uint16_t*)(g_active_config + 4);
        *calibration_field += offset;
    }
}

int main() {
    uint8_t config_a[32] = {0}; // A mutable config block
    const uint8_t config_b[32] = {1}; // A read-only, default config block

    // Scenario 1
    set_active_config(config_a);
    apply_calibration_offset(100);

    // Scenario 2
    set_active_config(config_b);
    apply_calibration_offset(200);
}

Conclusion: A Tool of Last Resort

We've seen that casting away const is one of the sharpest edges in the C language. It breaks the compiler's trust and opens the door to severe, hard-to-debug errors.

Key Takeaways:

• Attempting to modify an object that was originally defined as const is Undefined Behavior, full stop. The compiler is free to make your code fail in non-obvious ways.
• The only well-defined use of casting away const is to regain write access to an object that was not originally const, but which you only have a const pointer/view of.
• The most common reason people reach for this tool—interfacing with a poorly-designed, non-const-correct API—is highly risky. It violates safety principles (like MISRA-C Rule 11.8) and creates fragile code. The correct fix is to improve the API's const correctness.
• In your embedded work, this can lead to hardware faults if you attempt to write to memory sections the linker has placed in read-only flash/ROM.

Preview of the Next Module:
This lesson concludes our deep dive into type qualifiers. We've focused on using the type system to create safe and explicit contracts. In our next module, "Advanced Pointer Applications and Performance," we'll start by exploring the opposite: void pointers. We will learn how to use void* for generic programming, a technique that relinquishes compile-time type safety in exchange for flexibility, and analyze the trade-offs involved.