Programming in Modern C with a Sneak Peek into C23 - Dawid Zalewski - ACCU 2023 

As a C++ programmer I find myself moving more and more towards C for performance and simplicity. C is truly a legendary language.

C is one rare language where you can do the same thing for 15 years and be called modern. And I like that.

back in the day (late 80s in a university environment) a unix administrator and resident c guru warned me not to be fooled by the small size of the language since i could spend the rest of my life learning new tricks and exploring its possibilities.

I first learned C in 1984, shortly after working a long time in assembler. I could not believe that there was a high-level language that was so sloppy, did not check anything much, did not give any warnings, just let your mistakes causes crashes and even bring down the whole machine in those day. Today I love C. It's minimal, the least "high-levelness" required to get one off assembler. It's small, one can can write a C compiler in reasonable time. It's best in class for performance. Today I also love Rust. Finally a high level language that banished UB and checks almost all silly mistakes I might make. While maintaining the performance of C and avoiding the monstrous complexity and ugliness of C++. And it interoperates with C very well. So I end up loving both C and Rust for polar opposite reasons. Rust will not replace C for me, they will coexist very well. I'm sure that is true in the wider world as well.

Designated array initializers are amazing and have a use. The trick here is that in the brackets you can use any constexpr expression, like enum values. So you can have a map from enum values to whatever you want.

C is like free will: If you do good, you're the one to praise. If you do bad, you're the one to blame. C is the only one worthy of applause!

This has been very interesting to watch. Thank you, Dawid Zalewski, for taking your time to make this presentation.

C has changed so much since I learned it in 86. C has barely changed since I learned it in 86!

c doesn't totally lack type safety. C just has this feature called 'manual polymorphism' :)

I write in C++ over 5 years, but nothing came close to C even now. Its a legendary language.

i love c c is best all hail c

What a fantastic talk. As someone who hasn't spent much time with C since college, this was very informative and entertaining.

Long live C.... the grandfather of all programming languages!

So C23 is basically C++, it looks like C is becoming what he always hated

You know there’s a problem when the format for your talk about why C is great is a quiz on how confusing C semantics are.

the invoke macro is genius, made me pause for a minute, the preprocessor magic will never stop to impress me

Ooooh! I use designated initializers for arrays all the time for a couple of things: 1) I often make static tables of data that are indexed by enum values. You just [MY_ENUM_INDEX] = {.the = data, .for = it} 2) Graphics code often uses integers for binding slots, so I initialize plenty of complex nested structures such as: .targets[3].blending_mode = BLEND_ADD or something like that where different shaders need to set data to certain indexes deep within a large, mostly empty structure. Designated init works *great* for this!

I had to wait 6 months to find this??? I'VE BEEN INITIALIZING STUFF WRONG FOR 6 MONTHS NOW!?!??! The shame, oh the shame!!!

I was taught C in 1981 as a new grad in Computer Science when working for a company called ARBAT by my boss Peter Madams. Best boss I ever had. We used Whitesmiths C on a PDP-11 and later on a Vax. 42 years later I am still using C/C++ in the financial trading industry, so I am very lucky that it has given me my whole career. My boss used to say, "There is no such thing as a correct C program, just one that has never gone wrong yet !!" This is as true today as it was in 1981.

Finished Effective C recently and started to do some advent. Man does it feel so nice to use the more modern features. It reminds me of a more stripped down Zig.

There is a lot that has been presented I already use regularly in my personal projects, especially for clearer initialization; my priority is always about how to make the code more understandable, discoverable and debuggable though: so many creative uses of macros, old and new, are banned from my code.

Thank you, I love C

45:35 the thing you're missing here is that these one-dimensional arrays "emulating" multidimensional arrays have several advantages over multidimensional arrays. A big one is that they are simpler and more efficient to allocate, deallocate and memset, since it is guaranteed to be one contiguous space. If you call malloc N times, then you have N spaces that are not guaranteed to be contiguous. As for not being able to understand it... skill issue. If you see the pattern enough times, y * width + x becomes obvious and idiomatic. Case in point, I understand that code perfectly fine. In fact, I find it easier to read and understand than the example you show soon after, where you create a pointer to an array of arrays and then collapse 3 layers of indirection into 1 in a cast at the end. I would not be confident that that would work if I were writing that code. The one dimensional pointer, on the other hand, is much easier to reason about, and you can easily write it in a way that it is more readable. You could collapse the size of a row into a constant called "width", or you could even make a macro to do the transformation from (x, y, width) to y * width + x. But when I see a pointer to array of array of scalar being cast to a pointer to scalar, that's a massive code smell to me. Very dirty cast IMO.

Can't wait for it to become common place in 2069

C is just better than rust and I love it.

I wish C had namespaces. I like those...

you can use c++ modern without the classes and templates and still can get the modern features that it provide

C programming language is a tool and the quintessential soul of computer architecture and foundational programming. It is akin to an elemental force that underpins the very fabric of computing, transcending mere syntax or semantics. This soul, deeply ingrained in the computing structure, migrates through various embodiments - from operating systems to embedded systems, manifesting its presence in numerous forms, much like an incarnation. Each new form it takes on, be it a simple microcontroller or a complex operating system, is endowed with the essence of computational logic and efficiency that C embodies. Just as a body may function with limitations but cannot exist without a soul, so too can modern computing operate with various languages and tools, but it cannot escape the fundamental principles and efficiencies ingrained by C. This language embodies more than just a set of instructions; it represents computational thinking and efficiency, acting as a cornerstone that builds the edifice of modern computing.

Cool. I’m getting back into C after a decade or so.

Great presentation. I think that the presenter should more real application of modern initialization in C. I suggest showing how compound literals (CLs) combined with designed initializers can simplify setup of complex tree of structures in Vulkan API. No need to create a bunch of auxiliary object and vectors. Just taking address of CLs or CL arrays gets the job done.

One change I would like to see in C would be to add a syntax like [*]= in array notation to allow for a "default to something other than zero" mode. Something like `double array[10] = {[1] = 3.14, [2] = 2.78, [*] = 6.02e23};`

I've been a JS/Python soydev for the past 5 years, basically because I learned to code specifically to work as a developer rather than to learn about computers. The last 6 months I've been coding multiple personal projects in C and I feel like I have a superpower now, I understand a lot of low level stuff that the high level languages hide and my code skills are much better. Probably learning C was the best decision I could make. I feel like I want to stop being a webdev because I'm sick of it, but I don't think I have the skills yet to apply for a full C/C++ job, that's gonna be a long ride.

25 year programmer here. I always knew C was a solid language, but I wasn't very productive in it. It gives you so much freedom, that without some knowledge of software design it can be difficult to build and maintain useful software. I learned so many languages over the 25 years, and it wasn't until I learned Golang and Rust that I actually understood how to design and build software correctly. When I came back to C, I had fresh eyes and I'm feeling like I can be productive in C. I'm still convinced C is the best programming language.

Long life to C

This is a really fun talk!

Great talk!

45:21 Assuming sz can get very big, the argument to malloc can overflow and create a smaller allocation than expected. There's calloc for this purpose. Thought this was common knowledge.

This talk is very interesting and i cannot program in C while listening. So I’m gonna watch this later. :P Btw i’ve been programing more than 15 years 20+ programming languages and now days programming back to C and Rust.

i think ill start using k&r after this

Best programming language that human kind invented.

1:22:34 I was unsure if the double cast was needed, but now I know.

15:42 that int (*pk)[ sz ] [ sz ] has the *pk in parenthesis because the array operator [] has higher precedence IF the parenthesis where not to be used you will have double array full of pointers to int which is a totally and completely differnt thing from a pointer variable , more so it will invalidate the malloc call , further reasoning *pk is a pointer to int therefore Encapsulates information about the data object aka int which is a 4bytes (32bits) this encapsulation/metadata if you want to call it such is what allows the pointer arithmetic to be performed it makes the pointer aware of the data object therefore when you add/sub 1 from it it will Move the instruction pointer registers exactly 4bytes using a LEA instruction it is extremely fast

1:08:46 The semantics associated with flexible array members are a bit weird. They're arrays of incomplete of an incomplete type, but one can use a compound literal to initialize the structure, so long as the flexible array member remains uninitialized. However, a flexible array member has no presence in the language itself aside from being a named field in a structure: it has no size itself, and it has incomplete type, so you cannot initialize it, yet you can still refer to it, and get its address. Also, the allocation is simplified to sizeof(string_s) + sizeof(char[len+1]) because there is assumed to be no padding between the length field and the flexible array member. If you add another field of type char between the two, you may find that the offset of the arr field is less than the size of the entire struct due to padding at the end, resulting in allocation of unused bytes. To use every bit of the space, you need to allocate the maximum of either sizeof(string_s) or offsetof(string_s, arr) + sizeof(char[len+1])

Either I don't understand or I found a bug at @45:45: In the line *(pK + i*sizeof(double[sz])) + j) = _gcoeff(sz, i, j) sizeof(double[sz]) is only valid if your pointer was a char*. it won't work because pointer arithmetic is performed relative to the base size.

Every time he says, "It's like in C++", I say, "Oh no"; "Oh no, they will make C look like that".

What! Are they trying to make C safer? Move responsibility from the developer to the compiler? Have they gone mad?

Amazing video with lot's of insights.

Very informative and entertaining

45:35 That's a mess because it's not correctly allocated as a multidimensional array. It's only being allocated as a single dimension, which will work, but it's a mess and/or behaves as a single dimension. If you want a multidimensional array, it really should be allocated multidimensionally. Which is to say, allocate your first array dimension and assign it to a **ptr. Then use a for loop to step through each element of the array, assigning a pointer to it for another allocated array of the desired size of your next dimension. Then it will behave as a normal multidimensional array, using standard arr[col][row] notation. No VLA's required. It just has to be freed the same way it was allocated. Example: #include #include int main(void) { int i, j, col = 5, row = 5, **arr = NULL; arr = malloc(sizeof(int *) * col); for(i = 0; i < col; ++i) arr[i] = malloc(sizeof(int) * row); for(i = 0; i < col; ++i) { for(j = 0; j < row; ++j) { arr[i][j] = 'A' + i + j; printf("%c ", arr[i][j]); } putchar(' '); } for(i = 0; i < col; ++i) free(arr[i]); free(arr); return 0; }

The new features are neat if they will help reduce issues without requiring modifications of the existing code. But things like that non-NULL check are wack, if you start introducing those things you might as well recompile your code in C++ with use of references if needed. Not sure why they decided to make non-NULL argument descripton so complicated. It makes literally NULL sense.

Adding auto with the same meaning as in C++ is a strange choice - I thing its generally a bad feature in C++ but at least has some utility due to long typenames, iterators, namespaces- but in C? Why?

Can the standards committee please, please, please remove the implied "promotion" of short unsigned types to "signed int"? It only caused bugs

16:30 Unfortunately this is also wrong, if it compiles, then only under C23. auto buffer = (char[42]){}; 1) the compound literal has an empty initializer list, which is not allowed according to ISO C (until C23 it was available as a gcc feature) 2) auto buffer : default type to int results in at least a warning (-Wall or -pedantic). 3) auto buffer : if the default type would be int (with warning) the type does not match, because the compound literal (char array of size 42) gives the address of the first element (char *) This would be a conversion from char* to int.

57:01 - Looks like a UB. Compiler will destroy our "NULL check" (Why even need that if "free" do nothing with null pointers) or destroy dereference of a null ptr at line 7.

28:15 mapping enums on values for example

c89 is all we've ever needed. repent, sinners!

How do I define a strong C programmer? Its someone that knows precisely the assembly code that will be generated by each corresponding line of C.

In the refactor example: why keeping the check for nullptr when he's using static 1 in the oarameter list? Shouldn't that prevent a NULL vec pointer being passed in?

tl;dr: I am looking for good old fashioned (hardcore) C and C++ books that are current (e.g. 20 or 23). I have an MSCS degree (with EE undergrad). I think it is one of the reasons I find efforts to dumb down the material mind numbing. Most of my learning has been through textbooks, and the Java/Salesforce developer guides provide a good textbook-like in-depth coverage of major topics. P.S: Happy holidays. Long version: Can anyone suggest good C and C++ books? I have not really coded in either for over 10 years. It has been Java and Salesforce (Apex) during that time. I post the above question because I am not able to find a good C++ book. I think the textbook-like book from Stroustrup would be OK if it was current. The Murach book seems like it is targeting learners who are new to programming. I find the pattern of material presentation mind numbing. To me it seems that to get a deep understanding of a subject you need to go through 10 mini-tutorials. And the video tutorials are no better.

Interesting talk, but there are a few errors. Around the 16:30 mark, he said that program was well formed, but he should have only said that it compiles. Using a magic number for the size of a buffer is a huge problem, but he didn't check the return value from strftime() which could lead to weird bugs and/or a segfault. The slide around the 18:15 mark was all kinds of wrong. The accept() function in that example only took one argument, not multiple. This may be a language barrier issue, but he should get someone to revise the text, and he misspoke with regards to what static meant in the argument, as it required *at least* 1 value to be in the array. One could attempt to rationalize that as enforcing a C-string, as in a nul-terminated array of char's, but it wouldn't do that as you could pass the address of a single char and it could be set to anything. The two slides at 23:00 and beyond have a weird comment that seems to equate zero initialization of a char * to the value "" which is incorrect as that would have it pointing somewhere and only a tiny percentage of niche systems allow data to be stored at address 0, which is why that was chosen as NULL. I still don't get why C needs a nullptr constant when we already had NULL, and if it's about casing, why do we need the `ptr`. If it's a type checked thing, then again, why `ptr`. This also relates to the addition of constexpr as I'd rather they just change the functionality of const but also, I'm not averse to defining macros inside functions and regularly do so, especially when it's just for that function, and aside from that, if it's about type checking, constant values can use type postfixes and there's always the standard #define SZ ((size_t)100) to give it a particular type, if you don't know the correct postfix. At 33:00 I actually agree regarding VLA's and generally try to avoid using them, but there are legitimate use cases since they allocate on the stack, and I would definitely avoid using a maximum allocation size for every use of one. Given that the stack is generally limited, it'd be better if the max value was dynamically checked either way, but if you need that much space that it would blow the stack then use the heap instead. Around 46:00 I would just use i[*pK][j] to avoid needing the extra set of parentheses. I still don't understand why so few people use this superior approach to referencing arrays of data to avoid LISP-ing your code. As for 1:07:00 and flexible array members, I find that generally it's better to not use them. It adds hidden complexity to structs and does prevent you from making arrays of them or taking the sizeof them, and embedding in other structs and yes, even directly initializing them. If you're worried about multiple allocations then use the strategy I employ where the container is allocated on the stack. While the separation is a valid concern, it's an overblown one for certain types, especially when we're talking about large data sets. The data will dictate more how it should be accessed than the few pieces of bookkeeping information, and from an ergonomics standpoint, you shouldn't be allocating for a single container on the heap ever.

my rule of thumb is. If a macro changes the C syntax, you shouldn't use it

I am probably an old retarded. I don't find much of "modern" C attractive. Maybe I am allergic to changes. I think one of the main advantage of C is that it does not change that much. So that both old and new code can be compiled on both old and new compilers (if you are lucky). And so that C remains simple to learn. And writing a compiler remains simple. Don't get me wrong, there are a lot of things that I don't like in C, for example the #include mechanism which basically implies slow compilations, some of the undefined behavior stuff, some aliasing rules which force the compiler to generate instruction to re-read unchanged memory... But adding an initializer that sets non referenced fields to zero? That sounds against C principles. Non-referenced fields should not be initialized. C is not Java or something. And the sizeof a struct with a VLA inside that returns the size of the struct ignoring the VLA... That sounds weird, almost buggy. And [static 1] for non-null looks awful. It would be nice to be able to define if a function can or cannot take null in one of the argument. But it should look a lot more straightforward, like a nonnull keyword or something. Or better, the other way around, a null keyword.

I don't know if I love or hate the fact that the only people using C nowadays are Python devs

Nice!, can we compare it with C3Lang

I don't like generics, INVOKE macro trick, and constexpr. I'm not sure about bool. The rest seems worth a closer look.

@18:50 Is it right? Looks like a no check for NULL ptr in this example and only warning for arrays with [0] size as expected.

at 31:45, section "Static vs. dynamic?"... why not use "int* numbers = malloc(sizeof(int[a_lot]));" instead of "a_lot * sizeof(int)"?

The program at 17:00 is malformed, but for none of the reasons listed. The main function is a function and requires to return at least 0 or 1 (EXIT_SUCCESS/EXIT_FAILURE) statement.

18:30 Unfortunately, this is not correct. The idea is to check whether the passed address belongs to an array that has AT LEAST (and not exactly) this many elements. void foo(char p[static 5]); char array[4]; foo(array); In this example, you would receive a compile warning. Both under clang and under gcc. The whole thing has its limits, of course. And of course the function cannot check whether a null pointer was passed if it was not already known as a constant value at compile time. foo(NULL) leads to a warning because a constant value was passed here. In the following example, the compiler has no way of determining at compile time whether NULL was passed. int x = 1; char const * p = "Hello"; if(x) p = NULL; foo(p); // No warning, even if p should be NULL The whole thing is not intended for this, but for cases in which a "real" array (as the address of the first element) is passed - and not a pointer. void accept(char const str[static 4]); char const a[] = "Hi"; char const * p = "Hi"; accept(a); // Warning with clang and gcc accept(p); // Warning with gcc (not with clang) Clang and gcc also do different things here to determine whether the limits of the array have been observed. For example, clang no longer warns at all if a pointer is passed. gcc tries - as far as it is possible at compile time. Unfortunately, the way it is presented in the video is not correct.

when are we getting rid of header files?

If designated initializers work differently in c and c++, but c++ is supposed to compile c code, does that mean that eventually requirements for designated initializers are going to be relaxed in c++?

Compound literals, don't they also exist in Java for example?

listen i'm either gonna stay at c99 or just go to zig

@12:53: Wow, so C23 made even more ways to get silent errors. Lovely! Compile your program in the new version, get different answers! Brilliant!

May I ask why line 4 in 15:51 works ? I thought an array definition would ask the compiler to automatically allocate the memory on stack, with size corresponding to the type and number of element it has ? And can someone also explain line11 in 17:51 ? 😂

oh nice a new standard i will never use

Is "Modern C" analogous to "Modern Ancient Latin"?

When javascript creator disclose his technique. Just my opinion.

C is the language which created the Cyber War Domain. The Hamburger+Cola of computer science. There have always been much better alternatives around: +ALGOL +PASCAL +MODULA-2 +ADA Plus some newer ones such as RUST and SAPPEUR.

it's indeed a great video a great video to keep me away from c...

Weird people of C++ community somehow flowed into the world of C and bring this mess. Long Live C17!

The truth is that programmers have to make a living and the market dictates demand for emerging languages such as Rust. In 5 years time there’s a suspicious chance that Zig will paint a great picture.

I'm trying everything here except for the auto keyword.

All these new features but just more confusion. What a missed opportunity! Speaking as someone who had worked with C and C++ in telecom industry for over 10 years. If you have a large team but without a very strict coding style and do not enforce it strictly in code review, you would have a big mess. Have not used these two languages for more 15 years. After watching this presentation, I can't say I miss them.

Turbo Pascal is much, much better 😊

automotive safety... we don't care about types.

I don't know man, this whole video feels like mocking C, showing whats wrong with it and still saying it's great.

Huh, never thought on using VLAs as an argument. I always thought it was just a retarded feature.

c is a mess, like c++ too many non sense addition instead of first just fixing the short coming of which there is a lot.

I don't like this talk. If you hate the language, why speak so much rubbish about it? So much FUD being spread about features that have a clear purpose and give a lot of flexibility. I think the author really likes to use something like Rust, or some other safe language, on a powerful machine. And he should stick to that. Case in point: VLAs. You don't have to use them if you don't like them. There's even a flag to turn them off. But in certain applications you do NOT have to check the size of the array, you need the space saving, and you don't have the option to ask for dynamic memory allocation. So VLAs are the perfect solution. If you don't understand their use, why make bold claims like "nobody uses them"?

99% of these features are useless.

auto should be banned. It's the worst thing added to a language. They can use keyword var like in C#. Anyway, I'm not going to use it in C nor C++.

I don't say C must die, but C must not be used in many applications where it is currently used because it is quite dangerous language. For automotive industry, nuclear reactor control, space industry or other real time and critical control systems please use Rust. It is hard to reason about C-written systems, and proove they are correct even in small programs. The Linux Core itself is a strongest proof of how mission critical system written on C, could have a bugs even after of tens of years of development and rigorous testing(by very high qualified C programmers), still showing itself as unexhaustable source of bugs. So, if one develops critical sowtware for automotive industry, aerospace, nuclear reactors control, etc please don't use C/C++ ever, use Rust, if you are worried about your loved ones.

Someone tell these guys C++ exists. And we invented the Internet, too, where you can learn it and other new modern stuff.

Ewww, C was always horrible :(

Thank you very much for mentioning MISRA. I've been programming C (medical devices, automotive, telecom) since working at Bell Labs in the 1970s, love it, but your methodology, coding standards, and process determines the literal safety of the outcome.

Are there any reference/resources (i.e., books, blogs...) that describe Modern C (besides the standard itself)?

46:00 - Is it really that bad? I remember trying to wrap my head around multidimensional arrays in BASIC when I was 14. But it's always `row*stride + col` for 2D. Always. It isn't that hard, right?

"... so you can impress your colleagues!" This is the mentality where things go south usually. If anybody catches themselves writing "fancy", "abstract" code just so that you can impress someone, please take a good hard look into yourself because that's the opposite of what you should be doing.

I still find that Fotran dynamic multi-dimensional arrays (allocate(pK(sz,sz)) and an intuitive access syntax, pK(i,j), much easier than this VLA syntax.