PostHole
Compose Login
You are browsing eu.zone1 in read-only mode. Log in to participate.
rss-bridge 2026-02-19T23:19:00+00:00

SE Radio 708: Jens Gustedt on C in 2026

Jens Gustedt, author of Modern C, senior scientist at the French National Institute for Computer Science and Control (INRIA), deputy director of the ICube lab, and former co-editor of the ISO C standard, speaks with SE Radio host Gavin Henry about the past 5 years in C, C2Y, and C23. They discuss what has happened in the C world since we last spoke 5 years ago, including how the latest C standard is going and what to expect. Jens discusses how the latest changes in the Modern C book apply to you, how a C transition header can help you get up to C23 if you're not there already, and presents a comprehensive approach for program failure. This episode explores C2Y, C23, bit-precise types, stdckdint.h, stdbit.h, 128 bit types, enumeration types, nullptr, Syntactic annotations, auto and typeof keywords, if let, as well as what's being added and removed in C2Y (possibly called "C28"), and Gustedt's four categories of program failure.

Brought to you by IEEE Computer Society and IEEE Software magazine.

Jens Gustedt, author of Modern C, senior scientist at the French National Institute for Computer Science and Control (INRIA), deputy director of the ICube lab, and former co-editor of the ISO C standard, speaks with SE Radio host Gavin Henry about the past 5 years in C, C2Y, and C23. They discuss what has happened in the C world since we last spoke 5 years ago, including how the latest C standard is going and what to expect. Jens discusses how the latest changes in the Modern C book apply to you, how a C transition header can help you get up to C23 if you’re not there already, and presents a comprehensive approach for program failure. This episode explores C2Y, C23, bit-precise types, stdckdint.h, stdbit.h, 128 bit types, enumeration types, nullptr, Syntactic annotations, auto and typeof keywords, if let, as well as what’s being added and removed in C2Y (possibly called “C28”), and Gustedt’s four categories of program failure.

Brought to you by IEEE Computer Society and IEEE Software magazine.

Show Notes

Related Episodes

  • SE Radio 650: Robert Seacord on What’s New in the C Programming Language
  • SE Radio 494: Robert Seacord on Avoiding Defects in C Programming
  • SE Radio 414: Jens Gustedt on Modern C
  • SE Radio 371: Howard Chu On the Lightning Memory-Mapped Database (LMDB)

Related References

Transcript

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Gavin Henry 00:00:18 Welcome to Software Engineering Radio. I’m your host Gavin Henry. And today my guest is Jens Gustedt. Jens is a senior scientist at the French National Institute for Computer Science and Control, Deputy Director of the IQ Lab, former co-editor of the IOC Standard and author of Modern C all editions.. Jens, welcome to Software Engineering Radio. Is there anything I missed in your bio that you’d like to add?

Jens Gustedt 00:00:44 Hello. No, that’s great. You got it.

Gavin Henry 00:00:48 Thank you. So, the goals for the listener today for our show is to understand what’s happened in the C world since we last book, if you can believe it. Five years ago, now back in 2020 when your book second edition came out, we’re going to understand how the latest C standard is going and what to expect if there’s anything coming up to explore the latest changes in your Modern C book and how they apply to the reader. Explore your C transition header to help people get set up on C23 if they’re not there already. Given it’s 2025 and you talk about a new comprehensive approach for program failure, I’d like to explore if we have time. So, let’s get started. So, what if you can recall has happened in the past five years in the C world? And bear in mind what happens in other programming languages in five years. Has a lot happened to C or not a lot compared to say Rust or JavaScript or how would you describe what’s going on?

Jens Gustedt 00:01:47 First of all, you have to know that C is really slow. So maybe that’s the reason also why we talked five years ago and not every year or something like that. Development goes slowly and we really only standardize things that are already implemented. So there’s a long cycle for new features to come in before you even see them. So compared to other languages, for example, which I most know the most, C++, they have a lot of more excitement and fuzz and things going on and do things and then they do them back and then they do another thing and then they do something which is not consistent. So, we try not to do that. We try to have a steady pace, slow but steady to go forward. One of the things which were outside of the C Standard was another say standard, a technical specification which talks about point of provenance. So, this helps for those who know what that is to deal with liaising of pointers and objects and things like that. And this is work that took us 10 years, something like that and was mainly led by PSUL from the University of Cambridge. So, this was a big effort which now is concentrated in one technical specification, which in some years perhaps might go into the C standard. This is really what one of the things that went on in addition to the C standard itself for the moment.

Gavin Henry 00:03:28 I’ll get that link from you in the show notes.

Jens Gustedt 00:03:30 Yeah, yeah, yeah, yeah. I’ll give you a link on that so we can share that. There had been a lot of discussions also about the security of C code compared to other languages. I was not always happy with these kinds of discussions because my main impression always has been there have been some major misunderstandings what Cs and what C can do and what C wants to do and what other languages make different and what cost benefit ratio is. C is a relatively specialized language where you can do many, many things. So, all security buttons are somehow off, and this is by design and that’s not an accident. So, if you don’t want that, you probably are programming in the wrong language in some sense.

Gavin Henry 00:04:19 Did the work on the pointer and object aliases help with security side of things?

Jens Gustedt 00:04:25 In the long run we hope that this will help. Yes, but this has to be integrated in compilers yet or stated a little bit differently. The compiler vendors really have to check if they are confirming to that model. So basically, everybody’s convinced that this is the right model, that basically everybody should be there and have that. But there’s so many details to check for the compiler producers that they wanted it to be a technical specification so they already have something written up but they have to check this over the next years implement stuff, which is perhaps missing and things like that.

Gavin Henry 00:05:04 Would it be practical to sort of explain an example of these aliases and how they help with security?

Jens Gustedt 00:05:11 The main issue which is in the title is provenance. So, provenance we define of a pointer is somehow to which object in a wider sense, this pointer is pointing. So every allocation and, say, if you call malloc or calloc or something like that, or if you have a declaration of a variable, gives rise to a different provenance. And if two pointers point to two different such things which were allocated at different times, compiler can know that they are really different because they come from something very far apart. And this can help by doing a lacing analysis and then being able to optimize because the compiler can prove that two pointers actually point to different things. So, this is basically the idea behind this. And then, getting this through all levels of the language and all levels of the compilers and everything, this is quite technical then in the details.

Gavin Henry 00:06:14 So this would do away with dangling pointers completely?

[...]

Original source

Reply