On the bright side, I'm having a very easy time making a program that has to juggle pointers around.

I still don't know what pointer is

@@CounterStrik614 it points

@@undeniablySomeGuy holy variables! will know that, thank you

@@CounterStrik614 i cast to a void pointer once and i haven’t seen the cat since

It is like a very effective Flashbang

It's my 2nd favorite part of the video. The whole time I was like, "lmao off someone is probably really pissed about this...".

Dark color schemes hurt my eyes. I can't even look at them for a minute without getting a horrible headache.

It's probably the best video on how to structure C programs, in history. I have downloaded it and kept it in every media files I got. Hopefully Eskil realizes how changing that video is. Even though I don't program in C in anything, it's really the best general programming ethics guide.

FI agree that compilers should be a lot better at explaining what they are doing. For instance syntax highlight code deletion. However, it should also do the optimizations that the standard affords it.

@@eskilsteenberg yeah it would be great if the compiler gave some notice that its just ignoring code because it thinks its pointless, like 'hey maybe use volatile' or 'this expression is always true' etc. its been a while so maybe they are warnings now but it doesnt sound like it lol

The story here isn't actually too hard to explain! If you remember back when GCC and clang/LLVM were at each other's throats for being the "better compiler", the number one issue was speed- the faster compiler, the one that won all the benchmarks, was expected to win the compiler holy war. Therefore, compiler developers put massive numbers of hours into making their compiler generate the fastest code possible. Until shockingly recently, they didn't really worry about the effects this would have on developers, so they didn't put nearly as many hours into warnings and heuristics that warn when the code exerts unexpected behavior. As a result, the warnings that exist are mostly for simple rule breaks, and there's just not enough reporting infrastructure for the optimizer to report that some function is being optimized out of existence in a way that's probably not what the programmer intended. The fix is to put pressure on the devs- either make the patches on your own and contribute them to the projects (the best option!), or repeatedly ask for improved UB detection and ask others to advocate with you.

@@cosmic3689 Right, more warnings about those strange optimizations are wanted. But there is a catch: macros sometimes result in such code, especially when used with literal arguments. So at the same time, there must be some method to avoid overwhelming the developer with such warnings.

​@@HauketalThe compiler invokes the pre-processor, it can report a few instances of an error, then summarise repetitions.

most c++ compilers allow for a restrict extension like __restrict for g++ and clang.........

Restrict, or an equivalent, is available in all major C++ compilers. That said, restrict itself is a woefully inadequate tool for working with aliasing semantics. It hasn't been standardized in C++ because it's fundamentally a dead end. Also, C++ is leaps and bounds better for SIMD programming relative to C. Libraries like E.V.E. or Eigen are literally impossible to write in C.

I had to stop watching about 10 mins in because of it. Seizure inducing.

I didn't realize that was the issue! Thanks for pointing it out, was also confused why it was misbehaving.

Rust is my language of choice these last three years or so. However I still love C and would be happy to use it where needed. I love it for its hard core simplicity.I love it because it has hardly changed in decades and I hope that remains the case. However I've have also use C++ a lot and absolutely refuse to ever go back to that deranged monster.

@@Heater-v1.0.0 Say what you will about C++, you'll have to square it with the fact that even the major C implementations (Clang/GCC/MSVC/etc) choose the "deranged monster" of C++ over the "hard core simplicity" of C. Simply put, the fact is that C++ is more popular than ever because it's actually *more* insane to use C lmfao

@@69696969696969666 The is true. Most of the worlds C compilers were written in C. C++ evolved from C and the compiler implementations followed. All seems quite reasonable. I agree that C++ offers a lot of conveniences that can make life much easier than C, although I'm still happy to use C or the C subset of C++ where appropriate. It is possible to write nice C++ code if one stays away form much of the ugliness the language. Unfortunately it's hard to do that on a large project with many people working on it as they tend to start introducing all kind of C++ weirdness. Anyway, all that long and tortuous history does not mean we have ended up in a good place with C++. Many agree with me. Like Hurb Sutter with.his C++Front work. And Hurb is on the C++ committee!

Yeah, i was surprise that he started explaining volatile accurately. So often, even from very brilliant people, you hear rants about volatile and how it does not mean what we think it means - and then it turns out they them self are giving false explanations.

Your code was buggy before you turned on the optimization flags, the optimization flags just revealed them. your strategy of testing in multiple different optimization modes is the right one!

And Pascal

Ill try but im not a youtuber so i have limited time.

@@eskilsteenberg understood just if you ever feel a little inspired like this one and How I Program C, a lot of fans will appreciate it I think 👍

Agreed, so cool that i accidentally stumbled on this video!

The compiler can't optimize away my bounds checks because I don't check in the first place. Hopefully in the long term the undefined behavior in my out-of-bounds array accesses will result in even greater performance. Ideally compilers will become sophisticated enough to replace my entire code base with "return 0".

There is a common pattern using a mechanic called "compare and exchange". Lets say you have a shared counter that is shared and many threads want to merriment the value. Each thread wants to access this value and add one to it. To do this you read the value, add one to it, and write it back. The problem with this is that between reading and writing it back some other thread may have incremented the value. so if thread one reads the value 5, adds one to it, then tread two reads the value and adds one to it, and then both write it back, then the value is set to 6, not 7, even though 2 threads have added 1 to 5. To deal with this processors, have a set of instructions that are called "compare and exchange" , thy let a thread say "if this calye is X, change it to Y". So our threads that use that to say: if the shared value is still 5 change it to 6. If two threads try to change 5 to 6, the first one will succeed, and the second one will fail, and will have to re-read the value and try again. This teqniqe is often used with pointer swaps. So you have a pointer to some data that describes a state, you read that state, creates some new state, and then uses compare and exchange to swap out the pointer to the new state. In this case you are using the pointer to see if the pointer has changed since you read it, and this is where an ABA bug can happen, if two states have the same pointer.

Yes, some kind of smart pointers can be easily implemented with C.

@@eskilsteenberg why is this advantageous to using a lock? Seems like a rather roundabout way to solve the shared resource problem

@@zabotheother423 Lockless algorithms are generally faster because they don't require any operating system intervention. Mutexes are convenient because if you use a function that locks them, any thread that gets stuck on a lock will sleep until the lock is available, and the operating system can wake up the thread when the lock gets unlocked. This OS intervention is good, because threads don't take up CPU while waiting for each other. On the other hand, sleeping and waking threads take many cycles, so if you really want good performance its better not to have a sleeping lock but just do a spin lock if you expect to wait for a few cycles for the resource to become available. This means that you can only hold things for very short amounts of time, so its harder to design lockless systems, but also more fun!

@@eskilsteenberg interesting. I’ve heard of lockless designs before but never really explored them. Thanks

Congratulation! you cracked it!

Thats a really good question! Ive been trying to figure this out myself. I think they are scared of overwriting padding because it may break some rare program, but they don't even do it with freshly allocated memory. They do it with memory that has been memset, but not memory that has been calloced. I think it might just be an oversight.

But that is not what is happening. His claim about the optimised being allowed to assume malloc always returns memory is strictly wrong. You can easily check that by looking at things like compiler-explorer. The problem is with Linux as the kernel will return a memory-address even if it does not have anymore free memory.

Why are VLA requirements ridiculous? What's feasible for implementations can change with time. The first cc(1) I used had =+ & =- and didn't even support K&R C or the C widely published in books. BTW the VLA inclusion unbroke the single error I made in an exam at Uni. which cost me a 100% result long before the C standard inclusion so you need a really good rationale.

@@RobBCactive It's ridiculous because only GCC properly supports it, and the feature was added and then deprecated and then re-added to the standard. This is an absurd thing to do, especially for a committee that is so overwhelmingly committed to keeping the language as much the same as possible over the decades.

@@greyfade compilers didn't support ANSI C until they did, obviously function prototypes are absurd by your reasoning.

@@RobBCactive That's a disingenuous argument. The situation is not comparable. C didn't add function prototypes to the standard and then remove them in the next version and then add them back in the next version. They didn't do that with any feature except VLAs. And they haven't done that with any other compiler-specific feature, either. They didn't add an MSVC-specific extension or a Clang-specific extension or a Sun extension that no one else implemented. They only did that with GCC's VLAs.

@@greyfade nope, VLA is implementable and understandable by competent people. You've made no case why VLA is not useful or impractical.

No it is not. C follows the IEEE floating points standards and most things are defined, the things that are not defined are platform defined, and not UB. Platform defined means that the platform should define what the behavior should be for that platform. Than means that it is defined and consistent, on that platform, but that it may work differently on other platforms. UB means that there is no defined behavior at all and anything can happen.

@@eskilsteenberg Ah good. Yes, most languages follow that one, and that bit of platform dependent behavior is also the reason Rust doesn't do floating point math in const fn (aka constexpr in C++). Just to expand my knowledge, if you know: This is assymetric with whole numbers, and in many instances you see floating point numbers get special treatment to follow that standard. Do whole numbers indeed not have a similar standard? It's certainly much less important for the behavior of code, the general type already gives all the info (minus, for C and C++, platform specific stuff like the mapping of int etc to size), so I can see why that would be the case.

Its not a struct its a union. A union is a struct where all members occupy the same memory, so writing one will overwrite all others. This lets you write a value as one type, and read it as another.

Yes, the C language standard also uses the abstract machine concept.

If you write nonsense code that gets into language or compiler details unnecessarily, you are not doing anyone any favors. Clearing the high bit can be done by masking e.g. x &= (1

@@gregorymorse8423 I don't. It was a bad example. I would never intentionally overflow a multiply. The only times I depend on overflow are for addition and subtraction. In 8 bits 2-251=7. This is necessary if you want to calculate the elapsed time of a free running 8 bit timer. People tend to think of number ranges as lines, which is why overflow causes some confusion. For addition and subtraction It can help to think of number ranges as circular, or dials. Then the boundaries become irrelevant.

@Michael Clift overflows are well defined behavior in twos complement number systems. And applications like cryptography rely on this, and deliberately overflowing multiplication when doing modular arithmetic is practically vital to schieve performance. That C has tried to be low level but introduced bizarre undefined behavior concepts all over to capture generality that is useless is beyond me. The formal concept is beyond the dial analogy that a+b is e.g. for 32 bit unsigned (a+b) % 2^32 or likewise for multiplication. C does seem to respect thus for unsigned numbers in fact, it's signed ones that are trickier to describe so they chickened out.

with regards to 34:32, copying the code as written in the video and compiling with just "gcc -O3 t.c -o t" reproduced the result for me on gcc 9.3.0 (ubuntu, wsl)

@@nim64 Thanks nim. I tried it with -O3 and now I see the symptom too (still on GCC 8.3.0). It appears to happen with any optimisation level apart from -O0

It doesnt happen.

Maybe you need to hire better trainers? 🙂

There is nothing in the standard that forbids this, but you are not alone thinking this does not make sense (many people in the ISO C standard group agree with you). People do file compiler bugs for this behaviour, and some compilers try to minimize this, even thought the standard does not forbid it. I think ISO will come out with some guidance of this soon-ish.

You should write a small game with code reloading. Like Handmade Hero. That'll teach you everything you need to know. You don't need to make the whole game, by the time you draw some textured quads and maybe some text, you will have learned.

@@MagpieMcGraw This is good advice.

Skip C and learn C++. Not only does C++ allow for all of the "low-level" bit-fiddling of C, but it also makes it possible to automate most of the uninteresting busy work required in C. Moreover, C++ is the language of choice for GPU/SIMD programming, as well as far better parallelism and concurrency.

Wait, what? Did he pass away?

@@cavasnel i guess the commenter worked with him togheter or something but no didn't pass away, hes still active on Twitter.

I was very surprised by this advice, given the talk seemed to be targeting fairly experienced programmers. Possibly the main reason I stick with C is its powerful preprocessor. If you know exactly how it works, you can create incredible powerful abstractions and generic code - all completely safe. I assume he meant people doesn't know how to do that, otherwise this would be a very poor advice.

@@tylovset I wouldn't use C because of the powerful preprocessor. If I want a language with a low level core and powerful abstractions, I'd rather use Scopes.

It just isn't true: the compiler can not and DOES NOT assume that malloc always returns a non-null value. But malloc is performing syscalls to ask the OS for dynamic memory and things like the linux memory allocation scheme is opportunistic: It will always give you a valid address and only when trying to access that memory will you know if you can really use that. but that is not a problem of C but of Linux.

I don't understand!? Who highlighted your reply to my post? If it was Eskil Steenberg then he seems to be disagreeing with his own statement at 1:04:04. What's going on? BTW, I don't claim to know the answer, I was commenting on the statement in the video, and assuming it was something Eskil Steenberg had experienced. @@ABaumstumpf