Is it safe to remove const via const_cast and invoke a non-const function that does not modify the resulting object?

Question

I know that casting away const-ness should be done with care, and any attempt to remove const-ness from an initially const object followed by modifying the object results in undefined behaviour. What if we want to remove const-ness so that we may invoke a non-const function which doesn't modify the object? I know that we should actually mark such function const, but suppose I'm using a "bad" code that doesn't have the const version available.

So, to summarize, is the code below "safe"? My guess is that as long as you don't end up modifying the object you're ok, but I'm not 100% sure.

#include <iostream>

struct Foo
{
    void f() // doesn't modify the instance, although is not marked const
    {
        std::cout << "Foo::f()" << std::endl;
    }
};

int main()
{
    const Foo foo;
    const_cast<Foo&>(foo).f(); // is this safe?
}

Answer 1

Undefined behavior with respect to const_cast is defined by the C++11 standard's §3.8/9 (§3.8 is “Object lifetime”):

” Creating a new object at the storage location that a const object with static, thread, or automatic storage duration occupies or, at the storage location that such a const object used to occupy before its lifetime ended results in undefined behavior.

and §7.1.6.1/4 (§7.1.6.1 is “The cv-qualifiers”)

” Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.

In other words, you get UB if you modify an originally const object, and otherwise ¹not.

The const_cast itself doesn't introduce UB.

---

There is additionally a non-normative note at §5.2.11/7 that “depending on the type” a write through the pointer or reference obtained from a const_cast, may have undefined behavior.

This non-normative note is so wooly that it has its own non-normative footnote, that explains that “const_cast is not limited to conversions that cast away a const-qualifier.”.

However, still with that clarification I fail to think of any case where the write could be well-defined or not depending on the type, i.e., I fail to make sense of this note. Two other answers here focus on the word “write” in this note, and that's necessary to get into UB-land via §3.8/9, yes. The to me rather fishy aspect is the “depending on the type”, which appears to be the significant part of that note.

---

^{1) Except insofar as UB-rules about other non-const_cast-related things get into play, e.g. nulling a pointer that's later dereferenced in a context other than as typeid-expression.}