It makes more sense if you think of
constas “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 volatilevariable can return different results when read different times.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)
I’ve never really thought about this before, but
const volatilevalue types don’t really make sense, do they?const volatilepointers make sense, sinceconstpointers can point to non-constvalues, butconstvalues are typically placed in read-only memory, in which case thevolatileis 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.
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.
C is dangerous like your uncle who drinks and smokes. Y’wanna make a weedwhacker-powered skateboard? Bitchin’! Nail that fucker on there good, she’ll be right. Get a bunch of C folks together and they’ll avoid all the stupid easy ways to kill somebody, in service to building something properly dangerous. They’ll raise the stakes from “accident” to “disaster.” Whether or not it works, it’s gonna blow people away.
C++ is dangerous like a quiet librarian who knows exactly which forbidden tomes you’re looking for. He and his… associates… will gladly share all the dark magic you know how to ask about. They’ll assure you, oh no no no, the power cosmic would never pull someone inside-out, without sufficient warning. They don’t question why a loving god would allow the powers you crave. They will show you which runes to carve, and then, they will hand you the knife.
You have a talent for metaphor.
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.
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.
If you have a memory-mapped peripheral where there’s a readonly register, I could see it being
const volatile.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.
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.
deleted by creator
That actually makes sense, thank you for the tidbit!
Still kind of an overkill solution, but at least it’s funny
Looks like they didn’t want anybody using the secondary tank. Probably haven’t had time to pull Dave’s body out yet.
const…ish
constn’t
Context is very interesting: https://stackoverflow.com/questions/4592762/difference-between-const-const-volatile
Const flags to the code that you cannot change the value, and volatile flags to the compiler that it’s not safe to change the value.
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
When you set the port speed to no negotiate.
deleted by creator
