If you have a memory-mapped peripheral where there's a readonly register, I could see it being const volatile.
this post was submitted on 25 Mar 2024
0 points (NaN% liked)
Programmer Humor
19463 readers
916 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
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.
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’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.
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 (?)
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.
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
When you program embedded you'll also dereference NULL pointers at some point.
More...
Some platforms can have something interesting at memory address 0x0 (it's often NULL in C).
In amd64/x86 kernel space you can dereference null as well. My hobby kernel keeps critical kernel structures there XD.
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.
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"
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.
Volatile means that the value should be read each time its accessed. It can't be cached in a register or the read be otherwise assumed and optimized away or the instructions around its access be reordered.
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.
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.
Extension functions are not the same at all. Extension functions are syntactic sugar. For example if you have an extension function like
public static class ObjectExtension
{
public static void DoSomething(this object input) { }
}
You can call that function on an object by doing object.DoSomething() - Yes. But underneath it's the same as doing ObjectExtension.DoSomething(object)
That function does not actually become part of the object, and you can't use it to override existing functions
A closer example of how to do something similar in a memory safe language would be - in C# - using something like Castle DynamicProxy - where through a lot of black magic - you can create a DynamicProxy and fool the CLR into thinking it's talking to an object, while it's actually talking to a DynamicProxy instead. And so then you can actually intercept invocations to existing methods and overrule them
Generally overruling existing functions at runtime is not that easy
That actually sounds pretty cool
Sometimes what I'd like to be able to do is treat part of an app as a core and the rest like user provided scripts, but written and evaluated in the host language and not running an embedded scripting language like lua with all the extra burden.
E.g. you have an image editor and you want the user to be able to write native functions to process the image. Or you have a game engine and you want to inject new game code from the user without the engine being a compiler or the game logic being bundled scripts.
You'd probably use a different approach for that. Like you'd make your program dynamically load all the .dlls in a "plugins" folder -
Then you'd provide some plugin interface for the users to create plugins, for example:
public interface IImageEditorPlugin
{
public void BeforeImageEdit(int[,] imageData);
public void AfterImageEdit(int[,] imageData);
}
And then you can load plugin classes from all the dlls with dependency injection, and execute them though something like this:
public class ImageEditor(IEnumerable<IImageEditorPlugin> plugins)
{
public void EditImage(int[,] imageData)
{
foreach (var imageEditorPlugin in plugins)
{
imageEditorPlugin.BeforeImageEdit(imageData);
// Do internal image edit function
imageEditorPlugin.AfterImageEdit(imageData);
}
}
}
This is a very simple example obviously, normally you'd send more meta-data to the plugins, or have multiple different interfaces depending on the kinda plugin it is, or have some methods to ask plugins when they're suitable to be used. But this way a user can provide compiled versions of their plugins (in the same language as the core application) - instead of having to provide something like lua scripts
Is this wrench made of chocolate?