Yes, please make a video explaining "pages, offsets, and how that all works". It's especially interesting how you accessed the page at time index 9:00. A more detailed explanation about that would be appreciated. Great content as usual, thanks.
@@anon8510 it's not in stone, but every modern OS uses 4k pages by default. You can use larger page sizes, but you only can do it intentionally and explicitly, OS never changes page size by its own. Also it requires the process to run with root/admin rights in most cases, and OS can be configured to not allow page size changing at all. So doing it in the userspace app is generally a bad idea.
On an embedded system it is very normal to have const volatile variables. Mostly these are const volatile pointers, for example const volatile uint32t *ptr; These (points to) memory mapped I/O registers that are read-only registers like a status register. No way that the program can change them but the hardware can and will do. From the program point of view the register is read-only/immutable, not constant. Note: this is the same for hardware drivers on a PC. I don't think it is undefined behavior this way, with volatile.
The way you masked off those bits to get the address of the page is extremely interesting! And indeed, I'd love to see more content about stuff like this.
@@SlideRSB you're right, I didn't realise that he hadn't undef'd it before. Having that in the video is kind of weird actually since he's showing invalid C code without actually mentioning that it's invalid. The compiler he uses is lenient and just gives a warning but another compiler could just refuse to compile it.
@@lennymclennington He mentioned a couple of times in his video that not all compilers will work the same way since the behavior is undefined for the situation he's presenting. He also suggestion more than once that we don't do what he's showing in any code we actually care about.
From what I can see, the compiler is treating a “const” as an unchangable value which is a constant. While it might be possible to change a const using some esoteric method, for those of us interested in writing and maintaining good C code, a const can legitimately be thought of as a constant.
The problem is that the compiler can only do that if the RHS of the definition is a literal expression as discussed. But C23 will add (a version of) constexpr to C which will make this stuff much better.
I think you are only looking at this from the definition and development side. In theory there is no difference between theory and practice, but in practice there is. This stuff has a real world impact on what the compiler can safely optimize. Compilers often do unsafe optimizations when asked, for example most compilers have a switch that assumes no aliasing between arrays. Projects often end up with unsafe optimizations disabled because the assumptions didnt always hold. Its 5 million lines of code now. -Wont Fix.
Not want to use enumeration constant for an array size: we used to! Enums predate `const` and other features, and were abused to provide properly scoped constant names (that is, not preprocessor symbols) for quite a while. If i recall correctly, when `const` was added to C, it still was not a constant expression like in C++, so you could not use a `const int ArraySize=64;` as a (regular) array size. Though now that silently creates a variable-sized array. When I learned K&R C in the 80's, function definitions looked different, there was no `void` keyword, and all structure fields had to be unique rather than the name scoped to that structure! And you could use the wrong name with an -> and it just uses that offset without complaint.
First let me say, you rock! I know I may have been one of the people who came off as a naysayer, but I think part of it was me stuck on the "not a constant" versus listening to what you were actually talking about, of which I understand now with this video. Kudos fine sir!
Thanks, this video was very useful to me. Sometimes, different languages use the same word to indicate different things, or different words to say the same thing, and then it happens that you get confused even on trivial things. Maybe when I work at a low level I should forget all abstractions and just focus on the machine.
The source of the confusion is likely C++ const. In C++ a const variable CAN be used as a constant expression if it is initialized with a constant expression, so it is a constant. (Or at least as much of a constant as the context allows it to.) Not only that but it is taught and recommended to use const (or constexpr since C++11) over #define because #define can cause issues with overload resolution and other type-sensitive issues. #define constants are pretty much obsolete in C++, but still an important part of the C language.
In my experiment this also works without having to get the page starting address. Just modify A's memory protection instead of the whole page. void *p = (void *)((uintptr_t)&A); mprotect(p, 2, PROT_READ | PROT_WRITE);
Const-qualified variables can't be interpreted as constant expressions as the value doesn't have to be provided at compile time. It is for locals for but not for parameters for example. void f(int const n) { // n is readonly, not constant. } int main(void) { f(rand()); } This compiles because regular values can be "promoted" to const.
C programmer: God why can't I have a language with a constant variable Meanwhile assembly programmers having an unspoken argument with 100 other programmers that none of them will change the value of a variable
Maybe I am remembering wrong, but I think I used "volatile const" for inputregisters on my μController because writing to them would mess up a whole bunch of code and i had to specifically tell the compiler that it had to check every time (yes the compiler was very weak)
7:38 Wouldn't that be the job of the loader? The compiler and linker put the constant in the read only section of the binary, but the actual protection of the region has to be done by the operating system (loader?).
Well, it could be done by the OS (loader) or in the start-up code we get from the compiler and libC. I'm not sure if this varies by machine, but on the machine (Linux) I'm currently working on, the loader starts the process (using the execve system call) and then the new running program (libC) does a bunch of setup stuff before calling main. I just checked, and one of the things it does is call mprotect to make several sections of memory read only. I haven't looked at the libC code, but looking at the addresses, I'm guessing that one is the call stack and that another is the mapped section containing the read-only variables. So, yeah, this could happen in either place.
Also makes me wonder how the behavior would change depending on where the compiler places static const variables...I think that's in bss rather than an rodata region?
I'm wondering how reliable the placement is depending on compiler switches also. Maybe when you optimize for size it put everything in one data segment, protections be damned, and so forth....
@7:40 something - (under linux) It has nothing to do with mprotect or mmap (well, actually mmap yes since that's how the elf loader uses an ELF binary) ! It's simply that the constant it located in a read-only segment in the ELF file (usually in the .text segment). And please, please please.. the issue is that you are using a feature of C which is specifically defined as "undefined" : you are breaking the strict aliasing rule ! (turning a const int * into an int *). In C it's as simple as this : symbol with the const qualifier should not and cannot be used as an Rvalue but only as an Lvalue ! Casting of symbols should only be applied to 'void *' - something used to move around opaque structure pointers. Also any reasonable compiler optimizer will just treat a const symbol as a literal if it knows the value. Note that using gcc (and to demonstrate it's VERY undefined.. ) : $ cat t1.c #include static const int A=1; int main() { int *b; b=(int *)&A; *b=2; printf("A=%d,%d ",A,*b); } $ gcc -O3 -Wall t1.c -o t1 $ ./t1 A=1,1 $ * It's obvious that through SSA optimization the C compiler understood we were talking about A all along and just discarded the *b=2 ! Looking at the generated x64 generated code it's just using literal 1 throughout ! $ gcc -Wall t1.c -o t1 $ ./t1 Segmentation fault $ * No optimization.. So it just went ahead.. and wrote to a protected segment ! Then you can make the symbol volatile - hilarity ensues ! Remember.. C is just a glorified assembler.. compilers will attempt to detect through its (somewhat heuristic) logic if you are trying to do something stupid - but you can always fool it ! If you *REALLY* want to shoot yourself in the foot using convoluted and obfuscating methods, it will eventually relent and let you (for example there are times you really intend to do something specific with a very specific compiler on a specific architecture and you know it's going to behave a certain way).
Please can someone give advice of how to effectively deprecate functions in a C library which is living in the wild? Love the videos btw, it's really helping me in my journey to become a more aware programmer.
I think you've confused more people with meddling with memory protection like this :) What I mean is people may think this is how it should be done, that "const" doesn't really mean constant and so it can be modified by finding the page base address and fiddling with its protection bits.
@@JacobSorber I find it hazardous to convey this sort of subtle information. Too often people don't focus, they do something else and pick keywords here and there, glossing over the content, getting the gist with minimal effort and missing important details such as this one.
While it is true that a #define can be redefined, that's only true statically. B would actually be constant at runtime, as something like "B = 7 "would not be a valid expression.
Unless you redefine it as something that's not constant. Let's say you want to read an error code in a library you implement, so you say, #define errno (*__errno_location()) and the function could be int *__errno_location ( void ); Just an oddball example.
The use of the const keyword does not say anything about the constness of an object. It just reflect the intention of the programmee/code not to change that object. If the compiler believes you, it can create an constant object for you (in for example read-only memory). We can have a const pointer to a non const object. You can pass either the address of a const object or the address of a non const object to a function that have a const pointer as argument. For example strlen() What should be the output of the following code: int a; const int *p = &a; a = 10; printf("%d ", *p); a = 5; printf("%d ", *p); Is this correct code? Or should p defined as: const volatile int *p; ? (Did not tried this code (yet).)
This is a good question. I didn't immediately get why your code might need volatile, but you're basically asking whether the compiler is allowed to replace the "const int *p = &a;" line with "const int *p = 0x42" (assuming "&a" equals "0x42"), right? I am not sure whether it'd be allowed to do that.
@@sanderbos4243 p is a pointer to a. a is a non const object. But p is defined as a pointer to a "const" object. That is perfectly fine as we do not change the object through p. But a itself is changed. How does the compiler know when dereferencing p that a has changed?
Yes this code is correct, and no, you don't need to use `const volatile int *p' for this. A conversion from T * --> const T * will always produce pointer that compares equal to the original one. From n1570 (Pointers): >> For any qualifier q, a pointer to a non-q-qualified type may be converted to a pointer to a q-qualified version of the type; the values stored in the original and converted pointers **shall compare equal**. (Equality operators): >> Two pointers compare equal if and only if both are null pointers, both are pointers to the **same object** [...] So both of them point to the same object, since in this case, none of the other conditions in the paragraph apply. And the address of `a' isn't suddenly going to change after the assignment, nor is `a' going to change into a different object. (Storage duration of objects): >> The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a **constant address**, and retains its last-stored value through its lifetime. [...]
I'm not a C programmer. I use C++ so a lot of C stuff I don't know. I watch this channel for its C++ centered content (of which there is very little of, we need more), but it's cool to passively learn about the C language too.
Once upon a time I would have said that knowing how C works inside and out would be beneficial for C++ -- but that was at a time when most implementations of C++ was still just as an advanced C preprocessor (fun fact: the pp in cpp originally stood for pre processor .. early implementations were a modification to... a stand alone C pre processor .. source file named cpp.c)
What is the definition of a constant in native programming anyway? Mayne only values that only can get folded in as an immediate value in assembly. This means that constexpr in C++ does not define a constant, since it is legal to take the address of such an object. But a consteval (c++20) function is.
If the compiler doesn't know the value of the const, as in its defined in another file but declared in a header, then for that particular module it would be faster to have a macro, but if the compiler is aware of its value and you have optimizations turned on, then they'll likely be the same. The best reason to use const instead of #define is for debugging purposes and in general you might want to avoid macros unless you're doing something that can only be done with a macro.
I'm really curious if the generated assembly would actually read from that memory address without needing to mark the variable as volatile if optimizations were turned off with -O0. Off to Godbolt, I suppose.
Aaaand (spoiler) It doesn't work, it still moves the literal 10 directly into the register before calling printf. /z/dqnMqaWc9 Edit: Interestingly, in C++, the volatile trick no longer works as the generated assembly fetches the value of A from a sort of "data segment" (where strings are also stored) in which a bunch of labels are defined right after all the code. Only then did -O0 come into play in altering the value of the const variable, but it's still required to be declared as `volatile`, even though the value 10 is still stored in that same data segment in the binary, effectively wasting space. /z/TEsbv46v8 Great last couple of videos, they really clarified to me what const actually means in C. Would love to see a follow-up on C++'s constexpr keyword. tl;dr: don't undefined behavior I guess ¯\_(ツ)_/¯ Edit2: Had to remove the Compiler Explorer links as they kept getting this reply scrubbed by youtube.
ahh so usually a readonly variable is actually stored in memory, it can be assigned by values that change during run time and constant variables are assigned at compile time and are not read from memory, and because C has no standardized behaviour for const in this case it is treating it as a constant value and in other cases at readonly values? did i get that right? sorry im still kinda confused by all that :D
The compiler can only treat the const variable as constant expression if it knows its value at compile time. So it depends on the definition of the variable being visible at compile time (same compilation unit/.c file) and it being a literal expression.
@@Spielix and that means the level of optimization also matters as to what form you get at the end of the compile -- the old strategy of concatenating all your C files into one file is an optimizatin switch these days (what does gcc call it? whole programs optimization or something? or is that microsoft?)
You can redefine anything with meta programming 😀. Macros without redefine or undef, const or what ever actually. Make dll, have program call into that, recompile dll with new name and swap. Before compiling dll, look for the macro or const and change the value in the source file, with some parsing program, a pre pre processor if you will. Bam, changed during runtime of the program and not UB. TADA! Can be done by a keyboard press. Well, after you've made the meta stuff and the hot reloading. Super good debug/development iterative magic voodoo
In Microsoft land, 0x00000011b is a valid way of expressing a binary value. MS uses them in error codes sometimes. 0x00000011b is a printing error I found on Google.
"Unless the program rewrite its code in Memory"... Is that really possibile for a program to rewrite its own code while running? It would be Amazing to see a video about
As with most computing questions, the answer is "it depends". But yes, in many cases a program can rewrite itself. I'll add that to the topic list and see what I can do.
Meaning "#define MAX_X 10" doesn't use up memory, while "const int MAX_X = 10;", does. And, as it seems in a useless way. My vote is for the "#define". I know, I know, a handful of bytes doesn't even worth the mention when programming for a desktop with RAM measured in GBs. But go use unnecessary "const variables" like that in a small micro controller with a few KB of flash and almost one KB of RAM. Yes, yes, yes. You can get a micro with 3 or 4 times the amount of memory for a few more cents....... ......a few more cents multiplied by one million units a year during a 10 year product cycle, for example. My vote still goes to "#define" for avoiding "magic numbers" in the code and easy tuning of the program features. After all I also use a lot of "#define" statement in the main header file of my projects just for selective compilation of functionalities in the code. It makes modular testing and debugging way more easy than having to deal with a monolithic beast. Nevertheless, I think the "const" keyword deserves its own dedicated video because it has a lot of use cases that are not always that clear. And can cause noobs some headaches when dealing with libraries where it is highly used.
@@Spielix Yep. For selective/conditional compilation and even for special debug builds, it more flexible to have specific "make" configurations and include the defines there. But when its only a handful of constants to avoid magic numbers in the code, it goes in the special header file that I usually name "appConfig.h".
In assembly, constants (EQU) really are constant because they are just literals with a name. That stuff in the const data segment on the other hand.... const is just a name too.
@@styleisaweapon Oof. When I said that I was thinking of things like DW, DB, DD, where you could define data in memory, and they memory could me modified by an instruction. True tho, I can't think of any way EQU could be manipulated
It's because they're overly pedantic. Sure it sometimes matters what the ultimate meaning of something is, but at some point you just have to stop nitpicking and say "yep, it's a constant", because for all but exceptional circumstances, it really is.
It's not C doing everything to make it constant, it is your compiler trying to make it constant but without breaking compliance with C. That's like if on a plane I say "The LED be bright when the button is pressed", well what forbids me to make the LED always lit, it does satisfy my condition, it's dumb but it works, well that the same thing with most compiler, trying to match all the C standard, but when not clearly specified by it, doing everything to gain performance.
6:55 You are invoking Undefined Behavior. You did say not to try this on programs we care about, but really this might lead to bizarre results if you optimize.
Read the other comments. There are real-world implications for some applications. In microcontrollers, if you define a register address as a const, its value could indeed be different every time you read it due to hardware interaction. Just because it's a constant doesn't mean you can always assume its value doesn't change. It just means it is read-only from your program.
