No, it's not. That's the whole point why compiler can't optimize it away. You can often see ("char *") casts from static "strings" in legacy APIs and libraries calls, because original authors didn't know or didn't care how to use const correctly (or at all). I, personally, use const a lot throughout my C code, when you get it, it makes debugging so much easier.
To reinforce the sibling comment's point:
A very common pattern is when a const variable resides in non-writable memory (happens all the time in embedded), - if you attempt to write to it, you trigger a fault.
So if you cast away constness to conform to some API and then read the value, everything is fine (aside from questionable API design, of course). Modifying the value is another story, though.
Your first part was irrelevant: if you cast away const, of course variable must have been const in first place. As other have already mentioned, casting itself is not an undefined behavior (and sometimes even have legitimate reasons, mentioned in my earlier post). On the other hand, trying to modify const variable though non-const pointer is undefined behavior.
P.S. if you downvoted to disagree with this (on my parent post), please provide an opposite example, because as a C programmer, I would really be interested to be proven wrong on this matter.
No, it could be mutable variable referenced/accessed (not sure of the right word here) in a function via either a reference-to-const or a pointer-to-const.
It seems highly non-intuitive to me that casting away constness works differently depending on whether the variable was defined const or not, but if that's the rules, that's the rules.
It's completely valid to use a non-const pointer to a const variable for reading that variable (this is actually quite common when interacting with libraries that are not const-correct). Undefined behavior only occurs when the const variable is being modified.
I think it is only modifying that non-const value that is undefined. If you use a nominally mutable value in a read-only way, then you are OK.
This is important because older libs that ignore (or abuse) const will often do read-only access to a char* or something. A nice example is that POSIX defines
int execv(const char *path, char *const argv[]);
That definition takes a constant pointer to variable chars! Worse, some people use the same signature for `main()` and also for libraries that parse `argv`. But none of them are actually allowed to vary those chars under Unix.
No, it's not. That's the whole point why compiler can't optimize it away. You can often see ("char *") casts from static "strings" in legacy APIs and libraries calls, because original authors didn't know or didn't care how to use const correctly (or at all). I, personally, use const a lot throughout my C code, when you get it, it makes debugging so much easier.