Extern is good when making a program with multiple languages(Assembly and C). You have a function in assembly and you want to use it in the c code. Edit: Wow, thanks for this many likes, didn't expect that

The "extern" keyword is necessary when you need to access a global variable defined in a different translational unit. You rarely need this feature since having global variables is considered an anti-pattern in the first place. However, there are a few cases where you cannot avoid it: I once worked on a simple hobbyist operating system written in C. The keyboard buffer was updated by an interrupt rutine whenever a key was pressed and released. In order for other parts of the operating system to read which keys were pressed, I had to refer to the keyboard buffer and the number of keystrokes in the buffer, as a "extern" variables.

Extern is essential in a lot of cases. Many source-to-source compilers depend on autogenerated global variables, and the only way to access a global variable defined in a different object file is by declaring it as extern.

"register" keyword is important (especially on microcontrollers) for doing very low level stuff when you must not mess up the stack and want to avoid assembly. Like working on task schedulers.

The auto keyword is useless in C because it's implicit so specifying it doesn't change anything

You need the extern keyword on a variable to tell it that you are declaring it and not defining it, and that the actual definition is in some other file. You can get away with it by omitting the extern keyword but it will be confusing since it may read as being defined, and without any assignment the reader will assume it is initialized to zero. The compiler will catch it anyway if you defined the variable more than once. But that's a rather painful reminder. When that happens, you usually just add the keyword to remind you that it is just declared and that the actual definition is somewhere else.

So here's a bit of a summary about the keyword `auto` prior to C23: ---------- What is the use of `auto` in C? ---------- `auto` explicitly specifies that a variable declared at block scope shall have an automatic storage duration. This means that the storage is AUTOmatically allocated when entering the block where the variable was declared and is AUTOmatically deallocated when exiting from the block (by reaching the end or by a `return`, `break` or `goto` statement). A variable declared inside a function (local variable) has an automatic storage duration by default. ---------- Why is `auto` not commonly used in C? ---------- Variables with automatic storage duration only exist inside a function. Since local variables have automatic storage duration by default, `auto` serves little to no purpose at all. int x; is basically the same as auto int x; given that `x` is a function-local variable. ---------- Why did `auto` exist in the first place? ---------- `auto` is historical. It is a remnant of C's predecessor, the B language. It existed for backwards compatibility with B code. ---------- Is there any reason to use `auto` in a modern C code? ---------- Practically, there is none. This keyword is probably only used by those who are very pedantic and want to clearly (and unnecessarily) state that their variables have an automatic storage duration. ---------- What does `auto` do in C++? ---------- C++ `auto` used to work the same way as in C, until C++11, where it was given a new meaning. Since C++11, it is now used for automatic type deduction. It can be used to specify the type of a variable or the return type of a function based on the return type of an expression (sometimes in combination with `decltype`). `auto` type deduction does not make anything dynamically typed. It is done at compile-time. Once the type is deduced, it cannot be changed. ---------- What does `auto` do in C23? ---------- Starting from C23, `auto` can now be used for automatic type deduction of variables, similar to C++11 `auto`. ---------- B Language: www.bell-labs.com/usr/dmr/www/kbman.html C auto: en.cppreference.com/w/c/keyword/auto C++ auto: en.cppreference.com/w/cpp/keyword/auto

I'm pretty new to C, but I was reading up today on how the "inline" keyword can tank performance if the function doesn't fit in the L1 cache, so how it's better to just leave it up to the compiler to inline functions when it wants to.

Register is a hint keyword and just because the five major compilers today usually ignore it doesn't mean that any C compiler on earth will for sure ignore it. The C standard does not force the compiler to put anything into a register just because you use register, the same way it won't force a compile to inline a function just because you use inline. But it's untrue that this keyword never has an effect in major compilers. E.g. there are three situations where GCC will generate different code when you use the register keyword: - When used as part of the register variable extension. - When -O0 is in use, the compiler allocates distinct stack memory for all variables that do not have the register storage-class specifier; if register is specified, the variable may have a shorter lifespan than the code would indicate and may never be placed in memory. - On some rare x86 targets, setjmp doesn’t save the registers in all circumstances. In those cases, GCC doesn’t allocate any variables in registers unless they are marked register. So this keyword does have an effect even in GCC and it may have a larger effect in other compilers depending on certain situations.

That's why I like that Rust does not use types like int or float. Instead you type i32, u64, u8, i128, f32, f64. Also, there is usize/isize for getting the most efficient indexing type for your platform.

7:34 You weren't alive at this time... I was, and was C developer. And yes _register_ saved my life when I refactored an image format converter, resampling, with big/little endian switching, my project went from 10 minutes processing by document, to about less than one minute, using _register_ . You just have to use it efficiently, because defining every single one as a register will bring nothing, while using it on the right variables (in loops), will be stupendous. But I guess that today, with caches we don't really need it anymore if our code is well written.

Some of those "useless" keywords are for systems-level programming and are still used today.

The register key word can be used with the inline asm keyword to specify a specific register for the variable (register int foo asm("eax") = 5;). This might be useful in systems programming.

Thank you for this quite interesting episode. Beyond 'auto' and 'register', I like to mention the unary plus-operator. Though it is no keyword, you can write some wierd expressions like +5 *+ + +9 which is actually 45.

I have never used int or unsigned int, I have always used int32_t or uint32_t, in fact, I don't feel comfortable when I see int in the code because that makes me stop and think for a second where the code is going to run. But if you use uint32_t then it will always be a 32 bit unsigned integer whether on an 8-bit micro or my 64bit Linux laptop.

Unless you are willing to use __asm__ which is not very fun nor elegant you'll need to use `register` for some low-level programs where the stack itself must be preserved, but the most effective aspect of this keyword is that like a register should work you cannot access its memory address, so if you want to make sure that during the entire program no (unknown) change to the variable has taken place you could declare it as a register thus any call to it by address won't compile. And anyways the reason nothing changes in the compiler when adding the register keyword is that some compiler straight up ignores this flag. Again, in some cases the compiler will ignore this keyword, but it is still a powerful check for a call by address.

to see the register in effect you can select for example compiler for Arduino, on that site you are using, (also a lot of MIPS and ARM compilers as well) and then you can see the difference in the produced assembly code

Auto comes from B where there were no types and only auto/extern I suggest reading the C89 rationale and the bell labs reference manual if you are interested

Interesting, I didn't even know auto existed to be honest.

Hmm, I'd probably guess "signed" since I can't off the top of my head think of an instance where it isn't implied if omitted (I just checked, and according to reference at least since C11 there is always _a_ default implication; for integers it is always signed, for char it depends on the architecture but casting a char to unsigned char and back does, by definition, result in the original value). So yeah, I'd say signed is functionally obsolete bar the edge cases of weird cross-compiling.

"It's going to depend on the machine you are running on" is pretty much true for the majority of C code to begin with, as that's the whole point why C even exist, it's a slightly higher level cross-platform macro assembly language, that frees you from targeting a specific machine but as a compromise makes litte guarantees to be able to run on almost any machine. Also funny how you now start to worry about different behavior on different machine and just a few seconds before you said "my machine has 32 bits int and 32 bits longs then what's the point of having long instead of int" where you seem to not worry about other machines at all, since it only matters how your machine works.

If someone is saying smthing about goto or register, remember that they are heavily used in the Unix world

The point of long double is not to get 128 bits but to get "as much floating point precession as possible" and if your system only has double precision, then long double is the same as double, so you do not lose anything by using it, you still got maximum precession possible.

I personally think register is the most useless, I personally never used it and as far as I know the compiler will ultimately decide whether a value belongs in a register or not if I understand correctly.

That was unexpectedly chaotic and I loved it

I've only watched until 1:29 and haven't seen the comments. My guess is the register keyword, because compilers have become so much better than they used to be, so I don't consider it that useful anymore. Edit: I didn't even know C had an auto keyword. TIL.

“Register” was much more useful back in the days before x86, when 8-bit and 16-bit CPUs were for most computers & not just limited things like embedded microprocessors. I wasn’t there for it, but my dad and granddad were also systems programmers and used C when it was brand new. Apparently it was very useful in the days of K&R C when POSIX was also emerging as a cross platform systems API spec, and most machines had very limited RAM with potentially wildly varying instruction sets (e.g. all sorts of weird address sizes, etc.). Register was useful for keeping your stack size below a quite low hard cutoff, and for passing data between C and raw assembly (which you still often needed to write OS-specific or resource intensive code in those days). Back then every company making computers had its own hardware, OS, compilers, etc. so you couldn’t just assume that the tools would correctly figure out what variables should go in registers; early GCC might do it right without the keyword, but Solaris or Deck might not.

Fair enough about auto, long, and short. Extern is useful when you have a variable defined in a library. Your code needs to be able to refer to the name of the variable, but the variable itself won't be defined anywhere in your code. It also tells the linker about the linkage for that symbol.

On microcontrollers I always use stdint, simply because I want to use as little FLASH and RAM as possible. On desktop for better or worse I stick with the regular short, int and longs.

There's a case not that rare that you may need to use extern (I needed in an exam and took some time to realize it). If you work with forks and events, you are mostly obliged to use some global variables to communicate between them. And if you use multiple files in a single program, then you must declare those variables as extern or otherwise there will be declared "twice". Imagine you have a main file, a functions one and a header file: you declare your global variables in the header as extern, and then include the header inside both your main file and your functions one. If extern is not used, the variables will be seen as twice declared and everything collapse.

i love reading books with c code published in the 80s and early 90s. there’s a whole bunch of keywords in there i’ve never seen anywhere else

The number thing I actually like how Rust does it, i8 i16 i32 i64 i128 for signed integers, u8, u16, u32, u64, u128 for unsigned integers.

What about signed? I have never ever seen it in use. Integers are signed by default. But also int might be useless, because you could write just signed instead. All others like unsigned long int would just be unsigned long etc...

Isn't extern required to avoid duplicate global variables? In the code base I work on we use extern regularly. I seem to remember leaving that word off one time and it resulted in a linker error complaining about duplicate symbols.

extern: quite useful for importing code from other languages (wasm in particular comes to mind) long: honestly just group long, int, short, float, and double together, they're all unsized register: kinda useful if you have a microcontroller, but mostly useless auto: practically useless, it's literally the default behavior for variables

I code a master source module that analyzes the command line parameters, and then the functions therein call functions residing in other source files. Extern serves a purpose. The GCC compiler does not like any variable to be used before being set, and it will complain if that happens (compiler flag for -Wall) . But, when the variable is set in one source and used in a second source, the compiler has to know to not complain. A complain message also sets up a returncode for the Make utility, which generally ceases to continue. Extern tells the compiler and also the linker, that it should not complain about "use before set", and also, to check for missing match. If the global variable is declared without extern, it is considered as locally global, to this source file only, By the way, I test my code with gcc and with clang, two excellent compilers.

"auto" might be useful as a documentation device, if you use an automatic variable where in similar constellations in the program it is static.

The only one I haven't really used is auto, and I think it should have had a similar functionality as in c++. The int,long, short types I agree though because for custom architectures and embedded systems, usually you use the types provided by their vendors' libraries. But you can use int for toy programs and experiments. All the others have specific cases where they are really useful, even necessary in some.

I took a microcontrollers course a year ago and we wrote everything in C. I remember we made use of the external keyword quite oftener but I don’t remember exactly why. I think it had something to do with using the same variable in several different files.

I might say register, maybe unless you work on embedded (especially since the compiler might ignore you).

There's an old FAQ that I still goto when I need a refresher on C language constructs: c-faq (with the usual top-level domain suffix, which I can't type out because KZfaq will flag it as spam) Question 1.12 talks about the "auto" keyword.

With long, I believe that stdint uses long but that depends on which libc you use. With extern and register, I use them a lot with kernel programming.

The only reserved word you mention is extern. I use it when I want to link C++ function to my C program. Is there another way that You know an I don’t know?

As well as the 'global variable' usage, 'extern' is also used with inline functions when you need to take it's address for either: a) passing as a function pointer b) linking in the event that the compiler decides to *not* inline for some reason Pre-C23, 'auto' easily won the 'most-useless' keyword in ISO C as the only time it wasn't redundant, you could instead just write 'int' explicitly (a whole character less!) It was really only there to support some code written pre-standard. C23 adds the C++-style use though, which actually makes it quite useful now.

I agree that "auto" is useless but register should still be given some importance because one should always prepare for the worst compiler, one with almost no optimization. Your videos are great, by the way!

0:56 Must be 34 keywords then. Bcs you have unsigned two times in the list

auto for defining a local variable inside a function is pretty much useless (it's basically the opposite of static), but what if you used auto on a variable defined on global scope?

If you build for Windows, you sometimes need extern to get some Windows' apis working, like dwrite for example.

idk how fedora's gcc is configured, but gcc doesnt let me compile globals if i dont use the extern keyword. not the case on ubuntu tho as for register, i think there might be a difference in speed if you have more local variables than free registers. like if you have 100 variables but theres one you will use constantly- you hint to the compiler that the one you will use the most should be kept in a register. methinks. ill try that one later on when i am on my coding machine

I use 'register' all the time to access i.e cache configuration or the chip debug options or stuff like the control bus of the cpu im working with. Sure, i could just inline some assembly but i find using 'register' makes the code cleaner.

I had to use extern in a separate global variables header file (clang 13), otherwise the compiler kept screaming that it couldn't find the variable.

Hi. I do not understand the useless of return keyword/statement. If anywhere in int myfunc(int a, int b) i put return(-1); this is clear to human reader and to compilers. Or still you want to advocate structured programming ?

extern is useful in header files for declaring stuff that works both in c and cpp

Don’t you have to mark declarations as “extern” for global variables in headers? I always have to and pretty sure I get errors when I don’t.

*For register keyword, you will see changes if you change the optimization level* of the compiler and whether avx or sse code is generated.

Nice video!

When developing for the TI-84 Plus CE, you can't rely on the size of an int being 32-bits wide. The eZ80 is a weird backwards-compatible version of the Z80 processor, and the eZ80's 2-byte long registers are now 3 bytes long. The size of an int changed to 24 bits because it fits the size of the multibyte registers. There is some work being put in to add 48-byte "short long long" numbers as well. It is strongly recommended to use the *unsigned* integer types as specified in stdint.h because it is a little faster to do unsigned arithmetic on the (e)Z80. There is also a floating-point implementation, but there isn't a double-precision floating point implementation yet. The double type is an alias to a float, but a double precision floating point implementation, if made, would probably get the name long double. However, TI conveniently provides routines for 14-DIGIT precision floating point values in their OS.

I once used a specialized C compiler for high performance custom processor that recognized Global registers. The register keyword enabled this behaviour. For extreme performance the global register enabled custom-hardware level capability. I've never used the"auto" keyword in the 200kloc of C code I've written

Long is guaranteed to be able to hold an address. How do you know what size you need for that?

0:47 Actually, you counted correctly, it’s just that “unsigned” is repeated.

If you want to directly interact with your machine such as reading a specific cpu register directly, "register" is indispensable. so yes it is not useful for those not dealing with low level but for core embedded guys it is quite useful.

Hey Jacob. Could you please make a video on memory sections with examples ?? Like what type of variables are stored in which type of memory?

I've programmed in C for decades and most likely, I've never used "auto" a single time. "register", on the other hand, I think I used back in the early 90s when I wrote a VGA graphics library for DOS. Not sure if it made any difference back then, but at least it felt good to tell the compiler to make this most inner loop a tiny bit faster.

Extern is common as a keybaord. You use it every time you need to define a global varibale in an header file such that it can be accessed from other C files! I mean it's one of the most common keyword that I use...

The register keyword is not as useless as it may seem. The functionality is used for two things. First of all, the fact that godbolt spits out register movement instead of RAM accesses is because the optimizer puts register there even if you don't. Without register being there in the first place, that wouldn't work. (Sure it can be done and is most likely being done not my stuffing the string in there but the functionality but the point stands) Secondly, it can be used for it's original purpose in low level computing libraries with long and complicated functions. It does make a difference when the function is complex enough that the optimizer may make mistakes, like multiple matrix multiplications for shading or similar. Sure splitting them in blocks makes it easier but the additional method calls and stack access does make a difference when something is run on a million verteces 144 times per second or more. Especially if it is older hardware that cannot profit as much from parallel computation on GPUs or if the task is another that cannot be done in parallel at all.

Yes register is complete snake oil with any common compiler these days. Newest clang++ will even make it an error when used (can switch it into a warning with the right compiler flags though)

what is said in the video about extern I agree with (communication of intent), which is important. However extern is fundamental in certain circumstances, f.e. see the difference in modern C between "static inline" "inline" and "extern inline".

The register keyword is not useless. Here is a short example: #include int main(void) { register const a = 23; int *b = &a; *b=42; printf("%d ", a); } This program does not compile, but if you remove the register keyword it does compile, the output is then 42 on my PC and 23 on Termux on Android.

My bet: Register Even though it sometimes causes changes in code, they are usually only at -O0. most of the times, when using -O1 or more, register is actually considered in all compilations by default

I do agree that the long keyword somehow is useless and obfuscates the code and portability a bit. However, the size of an int ist most of the time the size of a word on the given system. So when you want a for loop to run 200 times, an int would just increment and compare if it is above 200. However if you specify a 32 bit int on a 64 bit system, it would increment, clear the upper 32 bits and compare. The other way around if you explicitly specify a 64 bit integer on a 32bit system, it would add the overflow (which is always 0) to a second 32 bit variable. So what I am trying to say: When you need highly performant code and you need it to be portable with similar performance, you might be best off with using the normal int type.

How about int? I can't think of any case where you need it. I believe every place you would need 'int' you can use 'signed' (or 'unsigned') alone since int is implied.

Create a typedef for the `long double` and write a scary comment saying it must be a float128 or whatever. (In C++ static assert the size and alignment and ieee traits)

It is necessary that only ONE module reserve space for a global variable or function. If several do so, then it is hit-or-miss whether the entity you call is actually the same entity you get. "extern" allows these extra modules to USE the variable whose space was reserved only once in a different module. "stdint.h" USES long, short, and char to DEFINE the "int32_t" for a particular architecture. Header files (*.h) are just regular C code collected together for a kind of functionality. Without long, short, and char, there would be no "uint16_t." If you declare more variables than you have registers, then "register" allows YOU to choose which variables are guaranteed to be in the processor registers. auto and int are not useful to new code, but are necessary for backward compatibility.

I use long all the time when moving data around with a void pointer because sizeof(long) == pointer size on the machines I use (ILP 32 and LP64 memory model).

As far as I'm aware, auto only exists _because_ of B, the language preceding C. In B, there's only 1 type, the computer word, or we'd just say "an int". You'd need to use auto in order to specify that the variable wasn't an extern (extrn). That's it, really. When C came around, it needed a much better system to represent this new PDP-11 character-thingie, so they decided to add types. Since, predominantly, variables are local, they decided to make "extern" the optional word and implicitly specify "auto". So why does C have "auto"? Because B had it. C compilers will, in fact, automatically assume the type as "int" (1 computer word) if you specify auto, but no type, just like B did.

I haven't written C code in about 20 years and this still amused me.

Want to really exercise things and the compiler and it's assembler output - create a function with lots of variables - enough so that they simply can't live in a register thru the function invocation to the end, and not even be in the stack (which is what his sample program did) . then go to town using register.

I seem to remember that sizeof is actually an operator not a keyword for some reason.

I know it was a joke but return does seem like it could be removed in many cases. instead of returning a value adjust a value at a provided address. this could theoretically reduce cycle time but is it worth it? probably not.

@0:45 - no, there are 34 keywords listed, not 35 as you wrote at the top right. You have 'unsigned' in your list twice, so the total count is 34.

My take on those: extern is useful for writing 'extern "C"'. Yes, that's C++ and not C, but oftentimes you need to write C code that will stay valid in C++, and 'extern "C"' is necessary for that. stdint.h types are generally better than short, int or long, but... stdint.h defines them in terms of typedefs into, well, short, int and long. So these are necessary to implement the standard headers at least ;) There are also a ton of headers that declare short, int and long arguments and return values, and I'd argue that when you declare a variable with the intention of the variable to go in or out of such API, it's the best and most portable approach to just stick to the same declared type. Which will end up having a different size on different platforms, but that's the problem of the library you're calling, not with your code. register is sometimes useful when used together with compiler-specific extensions, to actually access a specific CPU register in low-level code, without using outright assembly. auto is completely useless.

Some people say compilers doing smarter than programmers. The thing is, sometimes we don't want the compiler to optimize our code, specifically for safety related industry. For every piece of code that we wrote, it can be peer reviewed so we know how it really works, maybe not best in the performance, but it is safe. With compiler optimization, how do you known it always 100% correct? Some useful code maybe optimized out!

I code with Linux and the int is 64 bits in size.. The long is 64 bits, and the long long is 96 bits. The long attribute has to be used with strlen(), and other string functions.. I usually have to cast the output of strlen() ;

Pre-C23 auto, if that still counts. For modern C, register but I'm not sure if that one can still be useful with certain compilers.

Re integer type sizes * The types in stdint.h are not mandatory. * Only the relative sizes are dictated, that is sizeof(long) >= sizeof(int) >= sizeof(short) >= sizeof(char). * A char variable has CHAR_BIT bits in it. CHAR_BIT must be at least 8, but it might be larger. Re how many bits a long double has, its sizeof(long double) * CHAR_BIT. You can static assert on it having sufficient number of bits. Note that today processors might give you more than you've asked for, e.g. a C compiler might translate floats to 32 bit floats, then the processor would auto extend them internally to perform multiplications, division, etc, then shorten the result back at the end.

To me the register is useful when used in good ways. For exemple I’m a loop. The compiler will not read the value X times and instead will move it into a register and keep it there for as long as the function in going

Here you got a great example of how you define a word. If I talk about "portability", I talk about the possibility to compile a program across a *WIDE* range of compilers - even legacy compilers like Turbo C or Coherent C (this one only supports K&R, really!!). No fancy *stdint.h* to be found here. The only way to get an idea of what a certain core datatype actually does is to make a program with a lot of *sizeof()* calls - or consult the documentation. So in my world *long* is not quite superfluous. What I tend to do though is make my own .h file with a lot of *typedef* where I can abstract certain datatypes like 32 bit signed, 16 bit unsigned, signed characters, etc. By matching certain compiler macros with certain definitions (e.g. *__TURBOC__* or *__GCC__* ) I can make the process somewhat transparent. Disadvantage: every time you add a new compiler you've got to update the thing. I agree with *auto* and *register* though. I've been programming C for about 40 years now and I *never* used them.

Long is useful in 16-bit era where it was only way to get a 32bit integer

Agree with your two picks. Register is a hint to the compiler and was mostly used in for loop variables but every compiler today will do that anyway. And auto wasn't ever that great to begin with. Even 40 years ago.

Most useless: register, inline, auto Almost useless: signed (since ints are signed by default, but the signedness of char is implementation defined, so it's not entirely useless), while (since it's kind of a special case of the for loop) Oh, and you have unsigned in your list twice, which probably explains why you said "34" but then thought you miscounted :P

Ah, exactly what I need to make my code even """"smarter"""" and more confusing for my groupmates! On that note, I've personally never used the keyword `restrict`, though I don't do super low-level programming daily (we did do stuff like coding malloc and associated functions with all the corruption-proofing and optimisation though)

One small detail you didn't mention about register variables is taht you cannot take the address of them. When that is relevant, I don't know.

I have used all the reserved keywords in C except for auto, register, and volatile. With register and volatile, I can think of cases where I would use them, I just haven't had to deal with those cases in real life. But auto, on the other hand, just seems completely redundant.

Class I never use that in C 😂😂

I really love your voice, your editing and in general the style of your videos, but with this one I noticed that even if the length is just over 10 minutes, the actual leaderboard started at 3 minutes, which in my opinion is a bit to long Great content btw

auto in C23 does (most) of the same thing as auto in C++. It's been redefined to deduce types but doesn't go quite as far as C++.

You can't take the address of a register variable. It can be used to say, I don't want to alias this variable...

extern is extremely important, it allows you to access a variable which you haven’t defined!

register will prioritize variables when you have a lot of them, i.e., typically more than six locals.

I was thinking 'auto' from the start of the video. I've honestly never used it. Now 'register' was in my vocabulary from first using 'C in the mid 80s.