I thought of it more in terms of changing constants (by casting the const away). AFAIK when it’s not volatile, the compiler can place it into read-only data segment or make it a part of some other data, etc. So, technically, changing a constvolatile would be less of a UB compared to changing a regular const (?)
const volatile is used a lot when doing HW programming. Const will prevent your code from editing it and volatile prevents the compiler from making assumptions. For example reading from a read only MMIO region. Hardware might change the value hence volatile but you can’t because it’s read only so marking it as const allows the compiler to catch it instead of allowing you to try and fail.
I thought of it more in terms of changing constants (by casting the
constaway). AFAIK when it’s notvolatile, the compiler can place it into read-only data segment or make it a part of some other data, etc. So, technically, changing aconst volatilewould be less of a UB compared to changing a regularconst(?)const volatile is used a lot when doing HW programming. Const will prevent your code from editing it and volatile prevents the compiler from making assumptions. For example reading from a read only MMIO region. Hardware might change the value hence volatile but you can’t because it’s read only so marking it as const allows the compiler to catch it instead of allowing you to try and fail.
I will not tell my kids regular scary stories. I will tell them about embedded systems
The very notion of “less of a UB” is against the concept of UB. If you have an UB in your program, all guarantees are out of the window.
I mean, changing a
constis itself a questionable move (the question being whether the one doing it is insane)