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.
I was thinking about telling them how in embedded systems it’s a good practice to allocate the memory by hand, having in mind the backlog, but yours will come first
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 const volatile value types don’t really make sense, do they? const volatilepointers 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?
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.
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.
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.
Idk to me it screams “solve this puzzle and win a free wrench” /s
I like the creativity of it, and it does solve the problem in a way that’s user-safe. I thought of removing the knob because that’s what I do with my barbecue as I store items on the grill when not in use. Remove knobs, put on grill, close barbecue, cover.
A lot of people won’t touch electrical, and the problem with modifying the wiring is you need to be able to clearly document or show what was changed in case it needs to be reversed later.
This is ugly, but it’s immediately obvious how to reverse it to anyone who looks at it. And that pipe wrench probably wasn’t being used anymore anyways. I doubt they tapped the holes, those are probably just self-tap screws that both drilled the hole and cut the thread as they screwed in. No one will call this an elegant solution, but if it works it works.
If you’ve ever worked in maintenance, active production, etc, you’ll be lucky to even have schematics. And trust me, there are a lot of hacks of people fucking with controls for 30+ years straight that soooo much of it is full of “fixes” like this, whether it’s something pushing a button in, or pieces of metal instead of fuses, or wires jumping over what’s “in the way” like whole safety systems and e-stops, contactors forced to run, etc etc etc.
lemmy.ml
Active