You can certainly change it. But should you?

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 const 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 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 const volatile 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.
- 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’ve never really thought about this before, but const volatile value types don’t really make sense, do they? const volatile pointers make sense, since const pointers can point to non-const values, but const values are typically placed in read-only memory, in which case the volatile 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.
- 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.

Some people hate that C is dangerous, but personally I like its can-do attitude.

“Hey C, can I write over the main function at runtime?”

Sure, if you want to, just disable memory protection and memcpy whatever you want there! I trust you.

It’s a great attitude for a computer to have.

Agreed. It's a very adult approach. C hands you a running chainsaw and whatever happens after that is your responsibility. It is also your responsibility to decide when it's not the right time to use C.
This is sometimes practical, too. For example, hooking and extending functions in compiled code that will never be updated by the original author, while preserving the original executable/library files.
- You can do that in memory safe languages too. Kotlin extension functions, for example.
I loved C/C++ in university, finally the damn piece of rock we forced into thinking was doing exactly what I told him to do, no more and no less.

This is actually how you should declare something that you will never change, but something might change externally, like an input pin or status register.

Writing to it might do something completely different or just crash, but you also don't want the compiler getting creative with reads; You don't want the compiler optimizing out a check for a button press because the "constant" value is never changed.

Yeah I stumbled on this too. Surely the joke should be const mutable, not const volatile.

If you have a memory-mapped peripheral where there's a readonly register, I could see it being const volatile.

What is the context of the original image?

Could be simply a way to make sure the button never moves again. I would have simply taken out the knob, personally.
- It could be about sending a message.
  
  A missing knob is easy to fix. Bolting a wrench to the housing holding the knob in place is very explicit. It screams "don't touch"
- I work on industrial controls. Very likely that the switch is momentary, meaning it'll go back when released.
  
  Sometimes there's a little piece of plastic in them to remove the momentary setting, but this works too lol. Fuck it, it's maintenance.
I'm sure they just needed a way to lock the selector knob to the primary position, and didn't want to rewire it.
- Drills and taps two holes, adds a metal strap, and sacrifices a tool to save a 5 minute fix of jumping over the contact with a 2" piece of wire lmfao

Just spin the pipe wrench open and slide it up then you can switch it back real quick.

Thank you for watching this OHSA message on bad lockout procedure, now back to your regularly scheduled programming.

Is this wrench made of chocolate?

Forbidden chocolate

const...ish

constn’t
- I’m giggling like a kid that finally got the candy from the top drawer. It’s beautiful.

Looks like they didn't want anybody using the secondary tank. Probably haven't had time to pull Dave's body out yet.

I've used it in the past when having flash memory blocks that could change but you need the compiler to put them into flash memory and not RAM. It's mainly to get the compiler to stop assuming that it can optimize using the default value.

laughs in evil PLC programmer A little forces enabled, a change here, and maybe just move this wire over there while I am at it...

This has 14 (Peter Cline) energy here for the photo. Keep the dials at zero!

I see a Java programmer evolves into a C programmer

volatile int blackhole;
blackhole = 1;
const int X = blackhole;
const int Y = blackhole;

Compiler is forbidden to assume that X == 1 would be true. It's also forbidden to assume that X == Y. const just means the address and/or the data at the address is read only. const volatile int* const hwreg; -> "read only volatile value at read only address hwreg". Compiler can assume the hwreg address won't magically change, but can't assume the value read from that address won't.

When you set the port speed to no negotiate.