It makes more sense if you think of const as “read-only”. Volatile just means the compiler can’t make the assumption that the compiler is the only thing that can modify the variable. A constvolatile variable can return different results when read different times.
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.
AFAIK when it’s not volatile, the compiler can place it into read-only data segment
True, but preventing that is merely a side effect of the volatile qualifier when applied to any random variable. The reason for volatile’s existence is that some memory is changed by the underlying hardware, or by an external process, or by the act of accessing it.
The qualifier was a necessary addition to C in order to support such cases, which you might not encounter if you mainly deal with application code, but you’ll see quite a bit in domains like hardware drivers and embedded systems.
A const volatile variable is simply one of these that doesn’t accept explicit writes. A sensor output, for example.
I’ve never really thought about this before, but constvolatile value types don’t really make sense, do they? constvolatilepointers make sense, since const pointers can point to non-const values, but constvalues are typically placed in read-only memory, in which case the volatile is kind of meaningless, no?
That seems like a better fit for an intrinsic, doesn’t it? If it truly is a register, then referencing it through a (presumably global) variable doesn’t semantically align with its location, and if it’s a special memory location, then it should obviously be referenced through a pointer.
Maybe there’s a signal handler or some other outside force that knows where that variable lives on the stack (maybe through DWARF) and can pause your program to modify it asynchronously. Very niche. More practical is purely to inhibit certain compiler optimizations.
It makes more sense if you think of
const
as “read-only”. Volatile just means the compiler can’t make the assumption that the compiler is the only thing that can modify the variable. Aconst volatile
variable can return different results when read different times.I thought of it more in terms of changing constants (by casting the
const
away). 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 volatile
would 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
True, but preventing that is merely a side effect of the volatile qualifier when applied to any random variable. The reason for volatile’s existence is that some memory is changed by the underlying hardware, or by an external process, or by the act of accessing it.
The qualifier was a necessary addition to C in order to support such cases, which you might not encounter if you mainly deal with application code, but you’ll see quite a bit in domains like hardware drivers and embedded systems.
A const volatile variable is simply one of these that doesn’t accept explicit writes. A sensor output, for example.
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
const
is itself a questionable move (the question being whether the one doing it is insane)I’ve never really thought about this before, but
const volatile
value types don’t really make sense, do they?const volatile
pointers make sense, sinceconst
pointers can point to non-const
values, butconst
values are typically placed in read-only memory, in which case thevolatile
is kind of meaningless, no?They do in embedded when you are polling a read only register. The cpu can change the register but writing to it does nothing.
That seems like a better fit for an intrinsic, doesn’t it? If it truly is a register, then referencing it through a (presumably global) variable doesn’t semantically align with its location, and if it’s a special memory location, then it should obviously be referenced through a pointer.
Maybe there’s a signal handler or some other outside force that knows where that variable lives on the stack (maybe through DWARF) and can pause your program to modify it asynchronously. Very niche. More practical is purely to inhibit certain compiler optimizations.