The curl project has decided to alter its vulnerability disclosure program procedure and starting _**October 26 2026**_ , we insist that all vulnerability reports submitted to us that are deemed to be severity LOW or MEDIUM should instead be submitted as issues in our GitHub repository. Only vulnerabilities deemed to be HIGH or CRITICAL will be kept private in the HackerOne tracker. Security researchers in doubt can still submit the issue on HackerOne and we can tell them what severity we deem it to be. Over the last few years, over 90% of all submissions could quickly be assessed to be less than HIGH. Issues submitted to HackerOne we deem are LOW or MEDIUM will be requested to be resubmitted on GitHub and will be closed as informative on HackerOne (and publicly disclosed). ## Avalanche survival tricks This policy change is entirely triggered by the current avalanche of vulnerability reports that keep pouring in. We see no end to them and we do not anticipate this flood to decrease within the next several months. We are struggling as a project as all key maintainers feel strained, overloaded and brought to the brink of what we can muster. We _must_ act to survive. This is our next step in a survival strategy. It might not be our last. We aim to not drown. ## Public vs private By opening up the process we allow the whole world to participate. Both in the assessment and understanding of the report and claimed vulnerability, but also in the creating and writing the advisory and figuring out details of when the issues was introduced etc. Ideally we get better help to make sure the fix is the correct one, that it fixes the problem, and any other related problem that is similar and that it does not miss a related problem sitting next to this. An obvious recent trend is that the moment we announce a new set of CVEs and their associated fixes, there is an army of AI-using researchers who throw all those at their models and harnesses to find similar mistakes or omissions in the fixes. By taking this process to the public all the way, ideally we get more help to do that scrutiny better _before_ we ship releases. We recognize that the amount of work needed per received vulnerability report does not shrink by doing them in public, but we think that we might share the burden among more people easier, and we hope that lessons and documentation brought up in these discussions will be easier to spot and learn from. ## The risks Several people have suggested there is a risk that researchers mistakenly submit severity HIGH issues on GitHub thinking they are LOW or MEDIUM. It is basically unheard of that a researcher would have _understated_ a reported problem so I consider that a low risk scenario. Also: there was already before this a risk that someone would submit a vulnerability report in the public, it is not a new risk. Handling some vulnerabilities in the public of course makes the immediately available for both good and bad people. This policy will give bad people a slightly longer window of opportunity to exploit weaknesses at the expense of existing curl users. That is unfortunate but we see no way of avoiding this. We limit this practice to less than HIGH for this reason: at least these problems are not terrible. ## Severity LOW We have discussed simply dismissing all severity LOW issues, but within the CVE program there is an appeals process and if we don’t hand out a CVE to an actual vulnerability, then someone else will do it. We thus cannot ignore true vulnerabilities, or they will come back to bite us nonetheless. We _can_ however resist and refuse silliness and I personally aim to deny and decline more vulnerabilities harder on the basis that they do not actually hurt any users or existing applications. ## Crazy combos A clear trend these days is that many newly reported vulnerabilities are figured out by AI models that create crazy sequences or option combinations that do something unexpected, but the sequence is something that aren’t likely to ever be used in the real world, or the unexpected that happens is something that occurs _every time_ so applications doing this would spot the problem immediately. I.e problems that have almost no risk to actually trigger in the real world. We save no users by insisting on doing the CVE dance for those issues. We only get work for ourselves and a whole world that has to act on them. ## Flow control it There is an almost infinite number of combinations you can use libcurl’s many options, protocol mixes and flexible API to do things that might not be clearly documented and the AIs will continue to try them all and together with the humans driving these checks they are super eager to treat every minor discrepancy as a vulnerability. We can’t continue down this spiraling path with our sanity intact. We don’t have the bandwidth, manpower or even will to handle a never-ending vulnerability reporting stream at this pace. I believe few software projects can stand this kind of prolonged high volume deluge for extended periods. Something needs to give way. ## How to assign severity We only use these for levels in the curl project: LOW, MEDIUM, HIGH and CRITICAL. Often we refer back to recently managed vulnerabilities to see how we judged them, but we also provide a set of basic guidelines. I’m sure we can also make them better and clearer.

In the curl 8.23.0 release we shipped a fix for one of the worst vulnerabilities in curl in a long time. We grade it severity HIGH. It is known as CVE-2026-92392 with the title _HTTP/2 upload Use-After-Free_. This post explains the bug, what the problem can lead to, and something about why it happened and what we have done to make it harder to introduce a problem like this in curl again in the future. This is a much simplified explanation. Please refer to the original report for all the details and the full reproducible Docker image for all the low-level fun and education you could possibly want. I highly recommend doing that; the report and the reproducible are awesome. ## Use-After-Free It is a use-after-free, which is a classic problem in memory-unsafe programming languages, like C, where we erroneously have a lingering pointer left, pointing to memory that is already freed, and yet we use that pointer and the memory it points to. This family of errors is especially bad when a malicious actor can affect the content that gets stored into that memory area that is still used even though it was freed. Tricking the program to do something unintended. ## HTTP/2 is multiplexed This problem involves HTTP/2. HTTP/2 is a multiplexed protocol, meaning that it handles multiple logic transfers over the same physical connection. curl needs to keep track of a number of transfers at the same time, and when data arrives or is to be sent off, it needs to keep things apart appropriately. ## Handles For every transfer done using libcurl, the application creates and sets up a dedicated _handle_. We call it an _easy handle_. This handle is kept around for as long as the transfer is in progress, and the application can close and free it once the operation is completed. When doing multiple transfers, multiple handles are used. libcurl also has _multi handles_ , which is a super handle type that holds any amount of _easy handles_. This handle, and the corresponding multi interface, makes it possible to drive any amount of concurrent transfers. A transfer done with libcurl always has at least one multi handle and one easy handle. (Sometimes the multi handle is hiddenly used under the hood.) ## The setup In order to trigger this problem, we need an application (such as the curl command line tool) to do an upload over HTTP/2 to a server. By default, libcurl negotiates HTTP/2 when a HTTPS:// URLs is used and the server agrees. When the upload has started, the server pauses the send by zeroing the HTTP/2 window size, returns a piece of the response and then it resets the stream, which shuts down the transfer – but not the connection. curl then correctly pulls down the entire transfer, but it accidentally leaves a lingering pointer to the involved _easy handle_. When the application finds out that the transfer completed (with an error), it subsequently frees the easy handle and then, and here comes the problematic part: cleans up the multi handle. ## The mistake At this point, the _easy handle_ was just freed but there is still a reference to that handle. When libcurl shuts down the multi handle, it misunderstands the situation, allocates memory to download data into, finds the still dangling pointer and manages to _download data_ from the server that ends up in the very same memory previously used for the easy handle. In this process, it sends off a request that leaks internal client details, which includes information about local addresses, which is crucial. Modern operating systems use Address Space Layout Randomization (ASLR), so a server needs this clue in order to generate a good attack payload. Subsequently, when libcurl deals with this received data (using the handle the dangling pointer points to) in the download buffer, it uses a function pointer that now has been modified by data just downloaded from the server, and then _it runs remote code_. ## An illustration Here’s a simplified 6-step illustration. ## Conditions to trigger In order to actually successfully execute remote code, lots of several specific conditions need to be met and we deem it extremely difficult to meet these requirements in the wild, which is why we decided this is “only” severity HIGH and not CRITICAL. 1. The victim needs to actually attempt to upload data to a malicious server, meaning that the server certificate must remain valid. 2. The size of the upload needs to be roughly the right size (~135KB) 3. The attacker needs to know curl’s architecture to _generate_ and deliver the right code 4. The attack requires a specific sequence of allocations and allocation sizes so that the data from the server ends up in the right place (from the attacker’s view). This pattern differs between Linux distros, libc versions/flavors, TLS certificate bundles, libcurl using applications and more. 5. nghttp2 and OpenSSL/TLS 1.3 behavior, including allocation effects around session tickets 6. The payload storage area is small (around 23 bytes) The most likely outcome of an attempted attack is rather just a crash. We estimate that the chance for a successful attack is slim. ## How was this found? This problem was found and reported by Luna Tong at Anthropic using their new OSS Scanner. Presumably this involves their AI models. ## How do we fix this? In general we have over the last few years been working on reducing the amount of internal pointers to handles that needs to be correct, and instead we store transfer identifiers that we look-up on demand. While this is a tiny bit slower, it is more foolproof when there are logical mistakes like the one mentioned here. We also of course continue to add more tests and we verify the code with more tools and analyzers in order to find additional similar mistakes. Multiplexed protocols like HTTP/2 have this challenge that there are many concurrent transfers going and they all have different life-times and with memory-unsafe languages, dangling pointer mistakes can indeed be fatal. This is of course no guarantee that we do not have or will not introduce another use-after-free in the code now or later. ## Again on the language libcurl is written in C – a memory unsafe language. With a _memory-safe_ language, this mistake could probably have been avoided. We have worked on curl for almost thirty years, and have over this time manage to make a rather polished transfer engine. For the longest time there really was no memory-safe alternative that also allowed libcurl to be a low-level library available on hundreds of operating systems and several dozen CPU architectures. It even barely exist alternatives now. We do not rewrite curl. Not into another language but also not in C. We are set to iterate, polish, improve, refactor over and over until the end of time. Porting curl to another language (like rust) would be a monstrous undertaking that would be slow and introduce lots of new short to medium term problems. Not to mention that the existing curl team is not rust experts and that libcurl is currently portable to many more platforms and environments than rust itself is. ## Release schedule When this vulnerability was confirmed by the curl security team just hours after it was submitted to us on September 15. We immediately realized the significance and decided to rush the pending next release. However, we still wanted to be careful, follow the procedures and not create any further problems or mistakes by stressing it too much. That’s how we ended up just shortening the release cycle with two weeks. Down from eight to six weeks from the previous release. This allowed us to also merge and fix many more vulnerabilities and general bugs in the same release. ## CVSS We never provide CVSS for our published vulnerabilities as we don’t think we can do a job there. Others will provide them even for our flaws.

PowerShell is a spiced up command line shell made by Microsoft. According to some people, it is a really useful and good shell alternative. Already a long time ago, we got bug reports from confused users who couldn’t use curl from their PowerShell prompts and it didn’t take long until we figured out that Microsoft had added aliases for both curl and wget. The alias had the shell instead invoke its own command called “Invoke-WebRequest” whenever curl or wget was entered. Invoke-WebRequest being PowerShell’s own version of a command line tool for fiddling with URLs. Invoke-WebRequest is of course not anywhere near similar to neither curl nor wget and it doesn’t support any of the command line options or anything. The aliases really don’t help users. No user who would want the actual curl or wget is helped by these aliases, and users who don’t know about the real curl and wget won’t use the aliases. **They were and remain pointless.** But they’ve remained a thorn in my side ever since. Me knowing that they are there and confusing users every now and then – not me personally, since I’m not really a Windows guy. Fast forward to modern days: Microsoft released PowerShell as open source on github yesterday. Without much further ado, I filed a Pull-Request, asking the aliases to be removed. It is a minuscule, 4 line patch. It took way longer to git clone the repo than to make the actual patch and submit the pull request! It took 34 minutes for them to close the pull request: > “Those aliases have existed for multiple releases, so removing them would be a breaking change.” To be honest, I didn’t expect them to merge it easily. I figure they added those aliases for a reason back in the day and it seems unlikely that I as an outsider would just make them change that decision just like this out of the blue. But the story didn’t end there. Obviously more Microsoft people gave the PR some attention and more comments were added. Like this: > “You bring up a great point. We added a number of aliases for Unix commands but if someone has installed those commands on WIndows, those aliases screw them up. > > We need to fix this.” So, maybe it will trigger a change anyway? The story is ongoing…

A synthetic library for bigstrings. Contribute to robur-coop/bstr development by creating an account on GitHub.

Over the years, we have received, read and handled way over _one thousand_ vulnerability reports filed against curl. We have seen most kinds. It is time for me to try to help future reporters by providing a short guide on how to submit a truly excellent vulnerability report to an Open Source project. ## **Researchers** We tend to call everyone who reports a security problem a _security researcher_ , because by the act of the submission itself they fulfill the definition. There are however many different kinds of people who submit reports; from the most rookie youngster with limited experience, to the multi-decade experienced senior in the field. Most reports submitted to a project like curl come from reporters who never submitted anything to the project before and are completely previously unknown. Many reporters use hacker handles or pseudonyms, so there is not a lot to learn about the person behind the report either. We don’t know the reporters’ age, experience level, employer, sex or on which continent they live. But also: none of those things matter. When you submit a vulnerability report, consider telling the project how you want to get credited, should they consider your report real. There is a potentially almost unlimited amount of security researchers that can find problems in a project. The project receiving your report only has a limited small number of overloaded maintainers that take care of the reports. Consider this imbalance. Make your report as easy as possible for the team to manage. ## **Finding** To us maintainers who receive a steady stream of vulnerability reports, it rarely matters exactly _how_ the problem was detected. Whether you fell over it by accident, you found it by reading every single line of source code or if an AI pointed it out to you, it has little relevance to the security team. The team primarily cares about if the problem is _real_ and if it is, _how serious the impact is_. ## **Really?** If the problem is documented, then it likely isn’t a vulnerability. This is a common theme in curl: people report that they can find something strange or peculiar to happen when they do something, only to have one of us point out that the action is either documented to have that side-effect, or the action was done in spite of clear warnings in the documentation. To make a good vulnerability report, you should _make sure_ you understand what the software is supposed to do – and what the documentation says its limitations and conditions are. A good Open Source project has those things documented. ## **Where** Figure out where and how to submit your report. If you found several problems, it is considered polite to ask the team how they want to receive the rest. As separate individual submissions or maybe as a curated list. Perhaps paced at a slow rate to avoid overflow. _Never_ circumvent the submission method suggested by the project. That is impolite. Consider the initial submitting of the issue to be the first step in a multi-step communication process with the project that will continue for as long as at least one of your reported issues has not been resolved or dismissed. This can be days, weeks or in some cases even months. Expect responses and follow-up questions. Be prepared to clarify, expand and maybe provide more code and reasoning. Remember that you submit vulnerability reports in order to help and improve the project. ## **Report** These days people like to create enormously long and detailed reports that have all the details, often explained three times and with several embedded lists using bullet points describing impact and providing more or less good analysis attempts. Your first paragraph of the report should be a human-written, brief explainer of what the problem is and what badness it leads to. You should be able to explain that in just a few sentences. It is a reality-check, because if you can’t do this, if you don’t understand the flaw enough yourself to write such a paragraph, then you have homework to do. Figure it out, then come back and write the intro paragraph. Having a quality intro saves a lot of time for the security team receiving your report. Be aware that the Open Source project you contact may be overloaded, on vacation or seeing your report as yet another duplicate they already saw reported seven times. Be helpful and respect that you add a load to a small team that probably consists of volunteers working on this in their spare time. Even if you have used a lot of or just a little AI when finding the issue and writing up the report, you must make sure that you _communicate as a human_. With your human communication skills. ## **Reproducer** Your report should contain a reproducer. Ideally a fully contained and stand-alone script or source code that the security team can build and run to see the vulnerability trigger. A reproducer helps prove to the team that the problem is real or maybe already an accepted risk or behavior. It is also convenient for the developers to first understand and reproduce the issue, and then they can convert the reproducer into a project test case for the pending fix. _Without_ providing a reproducer in your report, you instead push that work to the receiving end. We still need the reproducer. We still need a test case. ## **Patch** Provide a patch for the problem. If you can figure out a way to fix the code to make your finding no longer trigger, that is great information for the security team and such a patch usually helps them understand the issue better and get a speedier result. It reduces the load. Sure, such a patch is often perhaps not perfect and it can usually be improved and expanded as the developers have a different view and a more nuanced understanding of the problem and the software architecture involved. It still helps. Getting 80% towards the target is still valuable. ## **Versions** Usually you should look for vulnerabilities in the latest version of the software, often even using an up-to-date git repository. Whatever version you used to find it, you need to specify that in your report. If the problem turns out to be real, which your report claims and you should never report anything if you don’t think so, it is then also immediately interesting to know _when this problem first appeared_. Which is the earliest version of the software that you can trigger this problem with? The project will want to know this to write up a proper advisory for the issue. You can help figuring this out by bisecting etc. ## **Collaborate** Remain available after your initial submission. In the curl project at least, we want to work with the reporter to make sure we get every angle and detail right. First, when trying to understand and assess the initial report and agreeing on a severity for it. Then, we jointly produce and agree to a remedy (patch) for the problem, which ideally means taking the reporter’s version and massaging it into perfection. If the problem is serious enough, there could be reasons to discuss a rushed patch release at an earlier date than the pending release would otherwise happen on. To reduce the time users in the wild remain vulnerable. Finally, we collaborate on the description and explainer for the problem that goes into the _security advisory_. ## **Advisory** For every CVE that is registered and assigned to a particular vulnerability, there needs to be a detailed security advisory written. It should ideally describe the issue, how it triggers, what it means, the impact, the affected version ranges and more. Everything related to the vulnerability that we can think might help users. Your job as a security researcher is to make sure the description in the advisory matches your finding, your understanding of the problem and that the description is understandable. ## **Learn** For every confirmed security report, the receiving project will try to learn from it and fix code and practices to avoid making the same mistake again. As a reporter, your job is to learn from the submission experience and try to improve your reporting procedure and approach for the next time. _Then submit your next report!_

Coordinated, confidential vulnerability remediation for the open source software critical infrastructure depends on

RFC 10008 is brand new a specification detailing the new HTTP method called QUERY: _This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests but can be automatically repeated or restarted without concern for partial state changes_ ## A GET with body For all practical purposes you can think of QUERY as a way to send a GET with a body. It looks exactly like POST, but done with another verb. Contrary to POST, QUERY requests are _idempotent_ – they can be retried or repeated when needed, for instance after a connection failure. ## curl it You can use curl to do HTTP requests with QUERY just fine. curl offers the `--request` option (also known as -X in the short form) that you can use like this: curl -d "data to send" -X QUERY https://example.com/ ## But redirects! There is one little caveat to remember with this curl option that changes the method. When _also_ asking curl to follow any possible redirects, it is important that you use a new enough curl version because you want the `--follow` option. **Not** the old `--location/-L` one. Why? Because the old option changes the HTTP method on all subsequent requests independently of what the server responds, which in many cases is not what you want. The newer `--follow` option instead acts according to what the HTTP response code suggests in should do. Stick to the same method again, or maybe switch to GET in the following request. ## Why? Why or when would you use this? First of course you only want to use this if the server supports it, but the spec offers some reasons why this might be a good choice: * avoid or circumvent URL size limits. Somewhere around 8000 bytes they start to no longer work reliably because servers and intermediaries set limits. * expressing certain kinds of data in the URL is inefficient because encoding overhead * URLs are more likely to be logged than request content

**The curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026**. We call it the _curl summer of bliss_. curl’s submission form on Hackerone will be paused starting July 1, 2026. Summer of bliss starts: **July 1, 2026**. 00:00 CEST Submissions resume: **August 3 2026**. 09:00 CEST The security email address will also be a dead end, as we will not process or otherwise care about security or vulnerability reports sent to us that way either. Whatever issue you find that you feel a need to report to the curl project during this month has to wait. curl’s Hackerone form opens for submissions again on Monday August 3. We do not accept vulnerability reports over email in general, and this fact remains during and after our vacation. ## Vacation for real The curl maintainers will use this time of less pressure to take in some extra air and to enjoy the summer. Maybe stroll outside a bit more. Breath. Some of us may spend some of this time to see other places. We may get some extra time to spend on fixing bugs or working on new code. Fun stuff! ## Side-effects As a direct side-effect of this summer of bliss, to allow us some more time to handle the issues that might have piled up for us in early August, **we also push the release date** of 8.22.0 two weeks into the future. Now scheduled to happen on September 2, 2026. ## Vulnerability rate As previously mentioned, we have been under a huge pressure for the last four months or so. Now we need some rest. We do not expect this deluge to be over. ## GitHub curl’s issue and pull-request trackers on GitHub remain open and active like normal. ## You too? If you and your Open Source projects also want to participate in the summer of bliss 2026: just do it and let us know! I would of course encourage you to do so. To take care of yourself as a top priority. ## The bad guys won’t rest Probably not. But we will. ## But what if there is an emergency Then we get to read about it in August. Or you get a support contract and we get to read about it earlier. ## Contracts excluded Everyone with a paid support contracts will of course still get full and appropriate service even during this period. Daniel, in a relaxed state. ## Credits The ice cream image was made by fotografierende from Pixabay

A sandboxed execution environment for unikernels. Contribute to Solo5/solo5 development by creating an account on GitHub.

This PR upstreams Merlin's typing recovery to the OCaml Typechecker. This new mechanism can be enabled with the -typing-recovery cli flag. When running in that mode, the typer won't stop at...

On cognitive DDoS and AI screen time for code, a proposal for voluntary disclosure in OCaml, iOS misery, releasing GeoTessera 0.8 and spatial indexing and the FP Launchpad launch at IIT Madras.

Proposing a voluntary, machine-readable AI content disclosure scheme for OCaml spanning opam packages, dune, and per-module attributes, aligned with the W3C AI Content Disclosure vocabulary.

Publishing the OxCaml Labs year-one review, POSSE and AI content disclosure for the web, adopting the geo-embeddings Zarr convention for TESSERA, action PROPL at PLDI, the death of the grant application, and NASA's new swathe lidar mission.

**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 * C wiki on standard – The Standard – C * Official Book (preferred) – Modern C, Third Edition * Free Book – Modern C * Blog – Jens Gustedt’s Blog * Book Blog – The C23 edition of Modern C * Bio – Jens Gustedt — Équipe ICPS – Informatique et Calcul Parallèle Scientifique * A common C/C++ core specification * * * ### 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? **Jens Gustedt** 00:06:18 This will not do away with dangling pointers by themselves. This will do away with, you have two parameters to the same function which are pointers and then the question is whether these can point to the same thing. And so, the compiler has to be careful or not whether when you change one of these things will change the other at the same time. **Gavin Henry** 00:06:41 Okay. That sounds a lot like what Rust enforces with borrower checking and things like that and sort of garbage collect memory. Map languages might do where they track every variable. **Jens Gustedt** 00:06:53 Yeah, this is related to these kinds of questions in C yeah, you only have these things implicit and so it’s basically a compiler who is then able to prove some things and this is where things get technically really nasty. So, we need a real good model and there’s some real formal specification in the mathematical sense in that paper was really difficult thing to do. **Gavin Henry** 00:07:20 So we could get in a situation where once you’re using an update compiler, I could find all these bugs for you because it’s tracking everything at that point. **Jens Gustedt** 00:07:28 And so one thing to note is also in the last five years compilers have been gotten really, much better than they were 10 years ago or something like that. They’re really able to track things much easier down and to warn you about stuff and things like that. So, there has been a real leap forward I think in what compilers are capable of, at least the compilers I know best which are these public domain compilers, GCC. **Gavin Henry** 00:08:00 Exciting times huh? **Jens Gustedt** 00:08:01 Yeah, it is, we are in exciting times. **Gavin Henry** 00:08:04 So our layer standard is C23 and that’s what your book’s been updated to K24. Can you give us a pitch of what it is? C23? **Jens Gustedt** 00:08:15 Yeah, so C23 is the first major addition to C since C11, so 12 years. So you have to have in mind at least a development cycle for C has been. So there has been an intermediate standard with force basically pfixxes in 2017 and so C23 is the first which has really new features compared to C11. Among these features are small ones and big ones. There’s really a lot. I could point you for example, one of the things you probably don’t even notice is that we reduce the possible sign representations to two’s complement before there had been other possibilities and now in C we restrict to two’s complement. Everybody uses two’s complement and anyhow you learn that in school and everything but now it’s official. Its C23 that this is the only way to represent signs for which changed some spelling of keywords. We added Cons X facility, we added auto and type of for type inference we added attributes which gives you the possibility to annotate, constructs in the language in a systematic way. **Gavin Henry** 00:09:36 Yeah, we’ll be going over some of those shortly in the next section. **Jens Gustedt** 00:09:39 Yeah, we updated the Unicode support. So, identifiers and C now are really ruled by Unicode. What’s possible to have in an identifier. There are clear Unicode rules for that and before we had some home brew tables of what was possible and whatnot. And so, we changed to be conforming to this other standard. We also added more facilities to the standard C library to transform different encodings. We add bit fitting utilities. Everybody probably knows how to do a pop count of so counting the bits of an integer and everybody probably does it wrong if they only have half an hour to program this. So, this gives you a unique way to do that with a function call and which is then optimized by your implementer for your platform what you have, we have checked integer metrics so you can check for overflow, and we have added Cons safety for some library functions. So, it’s just rough, very rough overview. **Gavin Henry** 00:10:49 Thank you. We’ll dig in a bit more in the next section. So how does that work? Say you’ve just explained there’s a new function to help count bits in an integer. So practical wise that would appear in glibc among other practice? **Jens Gustedt** 00:11:05 This appears or let’s say the different, all the compilers already had of have it with different names and so we are just putting some glue on top of it, which is a unique name. And glibc then would provide that in a header too. So you can, **Gavin Henry** 00:11:25 You can get an updated version of GCC that comes with the headers. **Jens Gustedt** 00:11:29 Yeah. So you can use that, portably for different. **Gavin Henry** 00:11:34 And that function is then defined in the GCC source code? Someone’s written it? **Jens Gustedt** 00:11:39 Yes. For most of these functions actually they exist for example in GCC they exist as built-ins. So, this will not even give rise to a function call at the end. This will be directly transformed into some assembly by the compiler. This is already built in with this prefixed underscore underscore built-in something behind GCC has a lot of them and what the header of glibc then only would do would give you basically macro interface which translates to this built-in of the compiler. **Gavin Henry** 00:12:13 And the GCC team would’ve done all the work inside? **Jens Gustedt** 00:12:16 Yeah, a GCC team had done this most of the work already before. **Gavin Henry** 00:12:21 And then to validate that, they’d look up the C Spec and make sure the inputs and outputs match what the spec says should happen.. **Jens Gustedt** 00:12:26 Yeah. Exactly, exactly. So this is the bit of work they have to do because when you standardize things like that, everybody has chosen a different name for these kind of functions and so we have to agree upon one name for a specific function and then everybody has to do some homework getting things right, with exactly the right name and right order of parameters and things like that. **Gavin Henry** 00:12:52 The stakeholders and all the different compilers would be represented in the C committee, is that how? **Jens Gustedt** 00:12:57 Not all but some of them, yeah. **Gavin Henry** 00:12:59 Some of them. And probably not for this function but for other functions. Would the internal implementation of these functions be obviously be different on what team has put them into GCC or Cline or wherever? **Jens Gustedt** 00:13:12 Yes. Even for these functions, these could be different because they might depend a lot on the process that you have. So, the processor may an Intel versus an RM may have different primitives and so the goal for the compiler team would be to match that to the good primitive, which makes this quick and easy. And there are certainly different choices to make for the implementation for certain things. And what’s only guaranteed by the standard is the semantics of such also, basically that it does the same thing. **Gavin Henry** 00:13:46 Would there be situations where your project or program would be faster compiling it, not compile speed, but actually runtime might be faster if it’s built with GCC or Cline because of those internal implementations? **Jens Gustedt** 00:13:59 Yes, sure. There are always differences in these things between the different compilers. **Gavin Henry** 00:14:04 And that’s something that you have to figure out I suppose when you do benchmarking? **Jens Gustedt** 00:14:08 Yeah, if you do benchmarking you can figure this out. **Gavin Henry** 00:14:11 It’s nice to think about how it goes from standard to implementation and actually getting in your hands and how that could be different as well. And if you’re on the GCC team or just a seed programmer in general, how do you recommend people keep up to date with not only what’s just in the standard, but do they just publish the standard and we’re all left to go and read it or is there another source of information that you can say these things would benefit you or does it just trickle down the stream tool or your compiler says something? **Jens Gustedt** 00:14:42 No, it’s really a process of compiler people adding things to their compilers and because they have a demand. So usually when there’s new feature there are people that like to have that then compiler vendors implement this and if a feature appears in several compilers and the community says, oh yeah, this one is now something that we think that is stable, then we are going to standardize that. So, this is really a feedback loop in that sense. **Gavin Henry** 00:15:14 Ah, okay. So, it’s back to front. **Jens Gustedt** 00:15:15 The standardization often then is only yeah, giving it a unique name to that function or something like that. **Gavin Henry** 00:15:23 That makes sense because you’re not just going to make up stuff in a standard just because you wanted something to do. Yeah, it’s because you’re trying to **Jens Gustedt** 00:15:30 There’s tendencies to do so also for certain things. But for all what I said, at least for the C library, this is usually really the case that this comes from somewhere and is then standardized. **Gavin Henry** 00:15:43 Okay, thank you. So is there going to be such a thing as C26 or is it going to be C34 or how do you think that will pan out? **Jens Gustedt** 00:15:54 Yeah, so there will be no C26. Okay. We are working on C2Y, so C26 would not exist. C2Y where Y is not yet fixed is in the works. So, there are already a lot of papers accepted for that. There’s an intermediate version of the standard where the editor has already integrated most of these changes. But this would certainly take us at least two or three years still. So, this might be 28, 29, something like that. **Gavin Henry** 00:16:28 That’s pretty good though because the last one C23, that’s another seven, six years for the next one. **Jens Gustedt** 00:16:33 Yeah. So, six years would be our usual schedule, let’s say like that by experience. But this time this will not be just a Pfixx release this time this will be a real feature release also. **Gavin Henry** 00:16:47 Okay. The one before was C11, so it’s quite fast. **Jens Gustedt** 00:16:49 There was C17 in between which was this Pfixx release. **Gavin Henry** 00:16:54 Okay. Yeah. And is there any major, you said there’s new features in C2Y? **Jens Gustedt** 00:17:00 Yeah, there’s some new features which for example, one thing we get from C++ actually this is definition of variables inside if and switch statements. I don’t know if you know about that feature in the expression part of an if and C++ you can first declare variable and then evaluate that variable. For example, if you’re making the system call, you can assign the result of the system call to a temporary variable for which only lives inside the if statement and then check for the value of that. **Gavin Henry** 00:17:37 Yeah, recently I’ve been doing mainly Rust programming. And that’s something you do in Rust quite often. **Jens Gustedt** 00:17:42 Yeah. So, this kind of need feature which is not very difficult to implement, we have added things to the pre-processor for example, we now have the counter feature. So, you have the underscore underscore counter underscore underscore which gives you at each time, which it’s evaluated in the pre-processor a new number. So, you can do that for saying uniquely naming some variables which are produced by macros or something like that. We have removed imaginary types. So, before there was a concept of imaginary type which nobody implemented. **Gavin Henry** 00:18:25 Is this one of the things that appeared in the spec first and then didn’t appear? **Jens Gustedt** 00:18:31 Yeah. So there was at one point in history there was one implementation for that. But the way complex numbers were described were basically described as being real and then plus this imaginary part and how this imaginary part which is then imaginary in both sense of the terms would look like and this complicated the writeup of the standard a lot and made it really difficult to read at some point. And so we decided that we get rid of that and removed all that from the standard and have just complex numbers. We have added complex literals which didn’t exist surprisingly before. So now if you just have a real number with the suffix I, then you get a complex with this number as imaginary part, things like that. And there are a lot of things which are already voted in favor but still need adjustment before they can really be included. So there’s a still a long way to go for this. We have a real large backlog of papers which we can only treat so much in the session that when we’re meeting. **Gavin Henry** 00:19:47 The only thing I remember about imaginary numbers is a university with engineering just INJ used to replicate. **Jens Gustedt** 00:19:54 Yeah, yeah. . **Gavin Henry** 00:19:58 Yeah. So, these things that are getting changed, what’s the process for that? You said they publish a paper; you review it as a board and then you chat about it. Or I think we might have spoken about this last time we spoke, but in the next two years or C28 or 29, what goes on in those years? **Jens Gustedt** 00:20:16 As I said, basically for example like this counter pre-processor feature, this is basically already implemented in every compiler. So, this exists. So, you have to write a paper to already first advertise that while you want that and then you have to provide text how this would be integrated into the standard. And then this goes usually over some iterations with the committee. There’s discussion on the email list and then there’s discussion session. **Gavin Henry** 00:20:49 Is this like a working group type thing? The mail list? **Jens Gustedt** 00:20:52 They are working groups but most of the things are done in C are done in plenary. We are only about 30 people or so which meet regularly. **Gavin Henry** 00:21:01 So somebody writes a paper and publishes it to that list for you all to consider? **Jens Gustedt** 00:21:06 Yeah. **Gavin Henry** 00:21:07 I see. Okay. I was just trying to figure out where people find those papers, but it’s all a proper process. **Jens Gustedt** 00:21:12 There’s a website for the C committee where you can find all these papers. **Gavin Henry** 00:21:17 We can put that. Okay, I’ll get that off you later. **Jens Gustedt** 00:21:18 Yeah, we can put that in links too and you can see all revisions of all papers and it’s really long list. **Gavin Henry** 00:21:27 Okay, I think we’ve covered our introduction a bit more than that. So, we might speed through the next section. So, I’ve called this section the latest C standard [C23] and upcoming changes. So, I think we’ve touched the upcoming changes quite a lot with C2Y, which sounds really cool. But let’s pull apart some of the things we just mentioned. So, I’ve got a few bullet points here that I’ll take you through questions. So why are these improvements to integers and enums needed that are in C23? And I’ve got a quote here where you say in the updated version of your book intro — or the marketing pitch for it, I think — there are new bit-precise types coined _BitInt[N], and new C library headers, for arithmetic overflow checks, for bit manipulation, possibilities for 128-bit types of modern architectures, et cetera. So immediately I thought, integers are integers; what’s changed and why are these things needed? So could you give me some insight to those? **Jens Gustedt** 00:22:35 First of all, integers are not integers. There are 15 different integer types — standard different integer types — and you have a lot of problems with overflow, with conversion. So, if the conversion is narrowing or widening and things like that. So, because we don’t have a BigInt type as other languages have, you always are reduced to something, some given precision, whatever that precision is what you choose, you really need to be aware of that. If you are going too far to big numbers, then you have wraparound or something like that or stuff like that. You have the problem of, if you are doing for example, comparison between two integers when one of these integers is signed and the other is unsigned, what should be the semantics of this comparison be and so on. So, this is not completely trivial in C how to deal with these and therefore we talked already a little bit of this bit manipulation thing. So, this offers new opportunities, new interfaces. **Gavin Henry** 00:23:46 So that would be the header? **Jens Gustedt** 00:23:49 Yeah, this is this thing. Standard checked integer gives you an interface where you can check for overflow. So, you basically do arithmetic, say an addition between two integers, and these functions which are in this interface in this header, they will not only give you the result of that addition but they will also give you a flag back whether or not you had an overflow in addition or not. So, you can do checks, you can abort your program if the numbers are getting too large or whatever you want to do when this goes down the drain. **Gavin Henry** 00:24:29 So up until this was standardized, people would be doing this anyway but just have created something themselves? **Jens Gustedt** 00:24:34 Yeah, well again there were built-ins for compilers which did that. So, this wasn’t a portable, not so easily portable or people did their checks by themselves and then with all the possibilities of getting this wrong. So, if you have time and look up on stack overflow for example, the questions on how to do that, you have a lot of answers and a lot of them are raw. So, you have some special cases which are covered. And the idea here really is to have that done on one hand correctly, which is already a good thing. And then also using as for the bit manipulation part, using already the right assembly instruction for example for that because most processors already do that correctly. They have this overflow bit and you just have to do the addition in the assembler and then read the overflow bit whether or not this work or didn’t work. **Jens Gustedt** 00:25:34 This is much more efficient and much safer. This is basically the idea behind. The other thing which you also mentioned is this thing with 128 bit types. The problem has been that we had an actually upper limit in the widths of integers, which was is the type uintmax_t, which on most modern architectures was 64 bits. And on the other hand, in many or there are really applications where you really like to have a wider types for example for cryptography or check some calculations or things like that. And the modern processes all implement these 128-bit arithmetic but there was no way to map them correctly into the C library. In the C language because we had this artificial restriction on how wide an integer could be. So, this was a lot of work of fiddling with the standard text actually to allow that to happen and now to offer the possibility to go beyond these limits that we have. **Gavin Henry** 00:26:50 And does the term wide int, is wide the bit size? **Jens Gustedt** 00:26:53 Yeah, wide is the bit size, yeah. **Gavin Henry** 00:26:56 And do you get input from going back to the standard from CPU companies that say we now support this, we should put something in the standard or did they release a tool set with the CPU as well? **Jens Gustedt** 00:27:09 Yes and no. We have one big player which is really invested also in the C standard, which is Intel, but they are mainly invested because of their compilers. So they’re really supporting Cline and they’re really interested in C from that perspective. We had this underscore bit in record N types which actually also came from Intel but for a very different reason that one might think they had this because they wanted to have such a type in FPJS and things like that where you really want to be able to design your integer type with every bit such that you can lay out your network of computing correctly in this FPJS exactly the resources thatÖ **Gavin Henry** 00:28:02 It’s not an FGPA? I haven’t heard that word since university and I think it’s Field-Programmable Gate Arrays, I was thinking of. But that’s not what you said. **Jens Gustedt** 00:28:12 Yeah, but that’s what I meant so okay. **Gavin Henry** 00:28:14 FPGAs. Yeah I remember doing that in my degree. Do you think these wider types, are they getting driven by machine learning type stuff, AI type stuff or where’s the need for them coming from? **Jens Gustedt** 00:28:27 The machine learning goes actually in the inverse direction, which is not yet covered by the C standard. The machine learning guide, they want to have floating point which is really short. So, for them float, for example, with this 32 bits is already much too large. They want to have floating points sometimes with 8 bits only or something because they really want to do approximate computations very, very fast and with really slow memory footprint for everything et cetera to do more and more. And then they only need to do some steps for the real position afterwards. So, they really have that and they’re currently — and this is one of the main reasons we haven’t standardized that I think for 8-bit floating point there are at least 10 different specifications by different providers which are all different in some aspect somewhere and what the mantissa is, or they present things. So, this is probably something we will see at some point to be standardized, but there’s still a long way to go because everybody now has their own 8-bit floating point somewhere and implemented and it’s not compatible to what the other guys are doing, and so it’s not easy to standardize. **Gavin Henry** 00:29:53 No, that’s interesting. I thought maybe it was like the vectors and things they use and just to speed everything up. **Jens Gustedt** 00:30:00 No, it’s more the crypto guys, things like that. So, it’s really interesting for crypto to at least to have bit operations on large vectors, and this works quite well for them. **Gavin Henry** 00:30:13 Excellent. Okay, so I’ll take us through a couple of more bullet points but we’ve still got a bit to cover because I want to talk about additions to your book, so we might move a bit quicker through these ones. So, what is a null pointer constant in regard to the standard? **Jens Gustedt** 00:30:28 Yeah, so before we had NULL all in capitals, which is just a macro which was somehow ill-designed or not well-specified. So, this can underneath the hood can be different things, and this led to potential problems, for example when you use that as an argument to print it for something like that. So, we had this sitting there; we cannot easily change things like that because it’s used by everybody. And so, we invented something new which hasn’t this ambiguity which now all-capital NULL has. So we integrate that really into the language and not into the macro pre-processor. **Gavin Henry** 00:31:14 All caps NULL macro. Has that remained the same since C was first created 50 years ago or so? **Jens Gustedt** 00:31:21 Yeah, basically. **Gavin Henry** 00:31:22 So all of a sudden in the 20s they decided no we need something else. It’s never come up before? **Jens Gustedt** 00:31:28 It has come up before. So C++ had, so this null pointer comes from C++. C++ has done this 12 years ago at least — I think in C++11 I don’t remember exactly — because they had exactly the same problem because they inherited that from us and they invented that, and so we just applied that same change to C. **Gavin Henry** 00:31:54 Cool. And what are syntactic annotations with attributes? **Jens Gustedt** 00:32:00 So, perhaps people know this underscore underscore attribute feature from GCC and Cline also implement that. Where you can add properties to a function, to a parameter, to a variable. You can, basically, there are a lot of attributes like that which were implemented before. The problem with the approach that they had was that this was syntactically not clear to which construct an attribute applies. So, you put sometimes you put the attribute in front of the function declaration or behind the function declaration, and these different places had different meanings and it was something yeah which engineers do. So, somebody invented something here and somebody there, and then you had a lot of add up of these kinds of features and the attributes — which is also a C++ feature which we adapted to C — is now a syntax annotation where it’s unique to which construct an attribute applies. **Jens Gustedt** 00:33:12 Basically, big rule is just as for other things, it always applies to the left. So, if you put an attribute for example behind after a function declaration, after the closing parenthesis, this would apply to the function to the type of the function if you would put it after the identifier it would only apply to the specific identifier, and things like that. So, you can annotate things like that. There are some standard attributes. For example, something like deprecated, you can mark an identifier as being de deprecated and so compiler will tell the user who uses that at every compilation, hey guys, remember this one you should use. And then there are a lot of vendor specific attributes where compiler vendors have the possibility to invent everything they need. They want to add to their compilers for flow analysis or for whatever feature they want to have. But it’s clear by the syntax to which structure of the program this applies. **Gavin Henry** 00:34:27 I’ve got four bullet points coming up. I’m going to just say them all out loud and then you can pick two of your favorites because we need to move on I think to talk about your book. **Jens Gustedt** 00:34:36 Okay. **Gavin Henry** 00:34:37 So the first of the four is what is generic programming with regards to type interference with auto and typeof? What is default initialization with curly brackets? What are compound expressions with lambdas? And what is so-called internationalization? So, which of those two get you excited the most that you’d like talk about? **Jens Gustedt** 00:35:00 I won’t talk about compound expressions lambdas because they’re not even in the standard yet and I won’t talk about internationalization because we already talked about Unicode and things like that a little bit. So let’s talk about generic programming auto and typeof and also initialization with brackets, which are both or all three auto and the brackets are features we also inherited from C++. So auto is the possibility to keep your code consistent if you have a function which depends on parameter X and this has some type and you don’t remember that type, but you need another variable of accelerator variable somewhere which depends on that and which should have the same type, you just type Auto Y=X and then Y gets exactly the same type and value as X and then you could continue. **Gavin Henry** 00:35:57 Yeah, it’s kind of like a dynamic language then, isn’t it? **Jens Gustedt** 00:36:00 This just helps you to stay consistent. So, if anybody changes X during development then Y will change automatically with it. And typeof is a little bit more complicated. It takes an expression or a type as an argument and then derives the type from that. This is used or useful in a lot of macro development or things like that where you like to be able to deduce types or automatically from what you get as macro agreements for example. Before initialization with braces closes say a loop or whatever before initialization and C you always had to put at least one initializer into these braces. So, you had to say if you have an array of A, type double of size five, you would have to put at least one zero into these braces for initialization and the rest would then be before initialized and now you can just omit everything and just put the braces. And then by that saying that everybody, every member of your array is the four initialized. And this even works for the so-called VLA, Variable Length Arrays. So even for errors where you don’t know the lengths where it’s determined not at compiled time but at runtime you can do that. So, the compiler will produce code that does this initialization for you. You don’t have to do a for loop to initialize all your, which you had to do before. **Gavin Henry** 00:37:42 To save the programmer some time? **Jens Gustedt** 00:37:44 Yeah and ensure that it’s consistent. It’s always these two aspects actually that you really have to be sure that people don’t do too much errors. **Gavin Henry** 00:37:56 So with these types of things, if you switch to using them, would you feel confident in using them or would you need to create some tests to make sure they’re doing what they should be or how do you advise people to get rid of code? Basically delete stuff because it’s now done automatically somewhere. **Jens Gustedt** 00:38:12 So first, again with these braces, compilers implemented that since a long time. Because C++ also has that so it’s already there and the compilers works, people use it and now this gives you the official stamp that this is, how it’s supposed to be and you can change all your code to that without any difficulties. So even if you have to backport it to some little bit older version of your compilers, this should work. **Gavin Henry** 00:38:44 Excellent. And you said compound expressions and they aren’t really standardized yet? **Jens Gustedt** 00:38:49 Yeah. Unfortunately, I put a lot of work in lambdas, and it was not taken for C23. I’m not sure that we get something like that for C2Y. I’m not sure people are very divided on that and then it’s really difficult to make progress. **Gavin Henry** 00:39:08 What’s the use case for it in C? **Jens Gustedt** 00:39:11 The use case for? **Gavin Henry** 00:39:13 The lambdas and compound expressions in C, why do you want it? **Jens Gustedt** 00:39:16 Yeah, lambdas for they exist in many languages. So for example in C++ are very useful tool if you have callbacks which you want to pass into a fraction and in C now the official way is always to create outside of the function you are currently writing before you have to write this callback as a separate function far away from where you’re going to use it and then you pass a function pointer to that function as a callback somewhere else in your code. So, you get these things very far apart and that makes it difficult to maintain and everything. So, lambda would be some sort of short function which you could actually put in place where you pass it as a callback and so everybody would see immediately at that place. Here I’m doing callback for, I don’t know what press button or whatever and you see how that works and where that is all in one place. **Gavin Henry** 00:40:18 I suppose a lot of arguments against these types of things is that your IDE will help you find things. **Jens Gustedt** 00:40:23 Yeah this is part of the argument and then there’s part of more or less small design questions on how to do that, how to do that syntactically. The question is if you have a lambda in a certain place, what does this lambda see from the surroundings? Is it possible to access local variables for example, in the surroundings or not? Or what would be the mechanism to integrate them? And there are people, it’s a little bit exaggerated but you sometimes you think people would kill each other for these tools, these things. **Gavin Henry** 00:40:59 Well people are very passionate about what they love. **Jens Gustedt** 00:41:01 Yeah, yeah. Stated like that they’re very passionate about things. **Gavin Henry** 00:41:05 Yeah, that’s the nice way to say it. I suppose we should talk about the bit that you’re most excited about and that’s your book. **Jens Gustedt** 00:41:12 Yeah. **Gavin Henry** 00:41:13 Modern C Third Edition. I can’t believe it. I’ve actually got the hard copy posted to me a month or two ago when it came out? **Jens Gustedt** 00:41:21 Okay. **Gavin Henry** 00:41:22 So was very excited to receive that. So yeah, let’s do the chat about that now. So given what we’ve just spoken about and we went quite deep in some new things that I wasn’t expecting to talk about which was great, what does the latest edition of your book bring to the C world? **Jens Gustedt** 00:41:38 So it has been completely reworked for C23. So, integrate all the shiny new features from C23. If you scan, it’s difficult on the hard copy so you would have to go to the electronic copy if you search for mention of the string C23 in it you get about 200 mentions. So, it’s all over the place and if you really want to know what C23 is that a really good way to do, you see it every here and there. There is this little thing which makes things easier where you don’t have to think about that, where you can do things easier with another feature, etc. etc.. In that sense it’s deeply integrated now into the book. That really was also the motivation to do that. **Gavin Henry** 00:42:27 It’s also really good that the standards are quite far apart in time. So, you get to update a book to the latest standard. It’s not like every couple years. **Jens Gustedt** 00:42:38 Yeah, yeah, yeah that’s right. That’s right. So the process of generating this new edition was also quite lengthy. So, which I did in some parts in parallel to what we did on the standard still, it took a lot of time to actually appear at the end. **Gavin Henry** 00:42:55 How many pages did you add? **Jens Gustedt** 00:42:56 Oh I don’t know. I don’t know. There’s someÖ **Gavin Henry** 00:43:00 I’ll work it out. I’ve got both copies here. **Jens Gustedt** 00:43:01 Yeah. **Gavin Henry** 00:43:03 I’m a bit of a fan boy . **Jens Gustedt** 00:43:05 So it’s thicker , it’s thicker, that’s for sure. But I didn’t do page counting. **Gavin Henry** 00:43:10 You talk about one of the pictures in your book that you’ve got easy transition header to get across to C23? **Jens Gustedt** 00:43:16 Yeah. **Gavin Henry** 00:43:17 Can you take us through that a little bit? **Jens Gustedt** 00:43:19 As I said previously, many of the features already are there in compilers. Often there is a, this is written, this has a little bit different name or perhaps maybe even arguments are in different order or things like that. What this header does, which you can download with the examples from the book is to provide you already the interfaces that match that on your current perhaps not so updated compiler, I only tested that for GCC and Clang so I wouldn’t know how this works really. Works for other compilers. But let’s say that these are probably the major compilers nowadays. So to give you an example, there is a macro in C23 which is called unreachable and GCC and Clang already have macros built in unreachable. And so what my header does is just matches this new name to the, so this is little bit the way this works. I’m not sure that you even would need that nowadays. I’ve written that, what? Two years ago or something. Now these compilers have officially transitioned to C23 already with their newest version. So probably won’t even need that. But if you still are stuck with a Clang from two years ago or three years ago or something like that, you could use that. **Gavin Henry** 00:44:55 Yeah in the C world that’s not unheard of is it? **Jens Gustedt** 00:44:58 This is not unheard of exactly, but you can use that and you be sure that your future proof for future changes once. **Gavin Henry** 00:45:06 Do you know how many versions of C standard that compilers keep around in their own source code? You know, if you march your code C11 or C89, still C89, but **Jens Gustedt** 00:45:17 GCC still has all versions of C. **Gavin Henry** 00:45:21 Wow, that’s amazing isn’t it? **Jens Gustedt** 00:45:23 It’s a lot of work to keep that consistent, so yeah. **Gavin Henry** 00:45:27 Wow, cool. So another thing that was really exciting in your book was what you’ve called a comprehensive approach for program failure that really piqued my interest. Can you take us through that if it’s possible? **Jens Gustedt** 00:45:40 That’s nice to hear because I put a lot of brain effort into that and one of the reasons I started writing this up was because I had the impression that there were a lot of misconceptions about what failure is in C or what a fault is in C and things like that. So basically, I was categorizing failures, program failures into four main groups. The first one is wrongdoing. So it’s your fault when you do something wrong, I don’t know you reference an bad pointer or you do whatever bad thing you can do and see this is basically the easy part where you should, whenever it’s possible to get a diagnostic from your compiler or your program should really fall very quickly or something like that. Then there is the next layer of faults that lead to program failure, which are program state degradation. **Jens Gustedt** 00:46:41 So for example, if you have storage, ex job, ex exhaustion. So, this is generally something which you can check. If you check for example the return of system calls. So, if malloc really gives you a now back then you know that something deeply went wrong with your program, there’s no storage available anymore and so you really should stop and do an emergency exit from your program or something like that. So that was a second level. The third level are unfortunate incidents. Unfortunate incidents are things that you don’t really notice, which are difficult to track and things like that. For example, like a race condition in between two threads in the threaded program. There are two entities doing their things and two thread for example and seen locally everybody’s doing the right thing but together they don’t work. This is something which you can basically only avoid by really careful design. **Jens Gustedt** 00:47:56 So this fault program failures for unfortunate incidents usually only appear when you have a bad design. But what is a good and what a bad design obviously is a really difficult question. And then you have the fourth thing, which is a series of unfortunate incidents where you are basically caught in a bubble. You have been doing decisions on your own, you’re going around the block in the city for example, at each corner you decide because of something to go to the left and if you do that consistently you will always walk around the block and never get out. So you are caught in some sort of bubble because you’re taking local decisions. Decisions which don’t lead you, which don’t have you make progress at some point. So this is also a really difficult design question to answer. So this is what failure is that the problem then is that you have to really distinguish the error. **Jens Gustedt** 00:49:07 So if you talk about, sickness or something like that, so this would be something which is wrong or goes wrong from the way it manifests from the symptoms. And this is something which is often conflated by people in C and generally in programming languages I think so. So symptoms can be compiled diagnostics, that can be compilation failure, that can be program termination or even worse, that can be real crashes, that can be erratic behavior, sound misfunctioning, all these different symptoms can appear if you have a failing program, you really have to navigate these and to know why your program failed and what to do against it to first of all try to do them to work that it never happens or if you can’t avoid it then see how to manage if it occurs and terminate your program for example in a controlled way. **Gavin Henry** 00:50:08 Okay. Just to summarize those four categories you created, you got what you call user errors? **Jens Gustedt** 00:50:14 Yeah, wrongdoings I call them. Yeah. **Gavin Henry** 00:50:17 Memory system issues. **Jens Gustedt** 00:50:19 Yeah, state degradation. So, memory system issues, but this can be, I don’t know, fight system full or things like that. **Gavin Henry** 00:50:29 And then three would be unexpected events. **Jens Gustedt** 00:50:32 Yeah. **Gavin Henry** 00:50:33 And four would be a combo series of those. **Jens Gustedt** 00:50:37 Yeah, a combo series of those which make you seem to do in progress but actually you don’t. **Gavin Henry** 00:50:42 Yeah. That could be something like you see in the news when, AWS goes down or something and something triggers something else and it’s not supposed to spike that much and then that doesn’t feed back to that and it keeps going and keeps going. That type of issue. Okay. How do we approach these four things then? **Jens Gustedt** 00:50:59 So the first is discipline for one’s wrongdoing, have a programming style, always keep to that programming style. Listen to your compiler. If they’re telling you here’s something fishy, there is probably something fishy and so you should do that. What the compiler suggests, generally you should against programs, state degeneration, you always should check return of system calls. So, every system call should either be in an if statement or you should take the return value into variable and then decide whether or not this was successful. **Gavin Henry** 00:51:39 Does the standard or compiler help with that type of thing? **Jens Gustedt** 00:51:42 Yeah, so usually the C library for example, you have for all faults you have return and you have, specified what happens, when an error occurs and so you can program against that. **Gavin Henry** 00:51:57 No, but does the compiler force that you check those? **Jens Gustedt** 00:52:00 There are possibilities that compilers are forced to check these, yeah. This is possible. So, these are the first two in that sense, this depends on the quality of your code directly, how you write it and that you follow style which is consistent in itself and you have the right tools, compilers or analyzers or something which give you hints on what to do. The other two are much more difficult to handle. So, they really need careful algorithms design. For example, race conditions between threads you really have to look and learn into and there’s a chapter in the book about threads and atomics and mutexes, and all that stuff, how you can avoid that race conditions occur from in the first place, for example. For this force, for these unfortunate incidents, it’s much more difficult because you have basically to have proofs on your algorithms that there is always progress. And this is not something which is in general or whether general rules or something how to do that. You really have to do something here too. **Gavin Henry** 00:53:17 And you could probably apply those four rules that you’ve created to any language really, any programming. **Jens Gustedt** 00:53:23 I guess so, yeah. Probably you could have that through, for different languages where you certainly have different kind and this is probably something where you could somehow rank languages whether or not the first two points are detected automatically or basically the syntax inhibits that you’re doing certain types of faults or something. So, C is probably on the lower end. So, you can probably end up trying to do that at some point improve C and the diagnostic that are given. For the last two, there’s basically all languages have these problems and basically all languages have the same amount of detail or whatever which they can help you or don’t. **Gavin Henry** 00:54:16 How do you yourself when you’re creating this approach — say the thing with threads example — do you have a set of example programs that you write to prove these things or work around them or how do you translate this sort of real world experience you’ve gained into your writing? **Jens Gustedt** 00:54:36 For all threading, for example, and problems like this, I think the C standard gives the right tools with atomics and muteness, and things like that. So, you really only have to apply them consequently and consistently to get things right. **Gavin Henry** 00:54:55 I was just thinking maybe you have your own C project that you break things and fix things and break things just to have a play and compare. **Jens Gustedt** 00:55:02 Yeah, so what I’m currently working on is having contracts for C, which is something like that to make some guarantees about things automatically, which is, I already published a paper for that but which hasn’t yet even been discussed by the C committee. But this would be a way to go forward to have actually more tools in the language in the syntax to guarantee certain things and have automatic more or less automatic proofs for certain things. So, this would be one direction to go, but this is early stage I’d say. **Gavin Henry** 00:55:42 Well I think that’s probably time up for us. Is there anything in your book that we’ve missed that you’re really proud of or even in not in the new edition that you want to highlight that you think will make people’s lives much better in the C world? **Jens Gustedt** 00:55:58 No, I think we covered it well. There’s so many things in the book, so you really have to think through it, learn it. **Gavin Henry** 00:56:07 So obviously the C programming language and standards and world is powering on, but if there was one thing a software engineer should remember from our show, what would you like that to be? **Jens Gustedt** 00:56:19 I think the most important thing is to stick to some sort of coding style or something like that. Be consistent. That’s really the most important thing. And listen to your compiler. **Gavin Henry** 00:56:30 That would solve 50% of your four. **Jens Gustedt** 00:56:32 Yeah. So basically compile things without warnings and you’re already quite good. **Gavin Henry** 00:56:40 Yeah. Because it’s there for a reason. So pay attention. **Jens Gustedt** 00:56:44 Yeah. . **Gavin Henry** 00:56:45 Do you think the C standard helps any other programming languages? **Jens Gustedt** 00:56:49 Yes, a lot. Basically, C is not only a programming language, C is also somehow a lingual front, how to approach, how to talk between different languages. So basically, all languages that you see today at some level they interface to C and then some of the work is done at C. **Gavin Henry** 00:57:10 Yeah, that’s what I think about. Like I was saying, I’m doing a lot of Rust work at the moment and I’m seeing more and more libraries be written in Rust and then they expose a C interface. And every other language then uses that interface to use that language. **Jens Gustedt** 00:57:24 And often it goes the other way around. For example, for Python, once you do want to do things efficiently and fast, people create some C library which they interface from Python. **Gavin Henry** 00:57:36 Yeah. And then that means everyone else can get it because it’s written in C. **Jens Gustedt** 00:57:39 Yeah. It’s written in C and then easy to use in Python. So, there are these compromises which are done today. **Gavin Henry** 00:57:47 Should someone learn C today that’s never programmed before? **Jens Gustedt** 00:57:50 Yes, sure, certainly. It’s really one of the programming languages with, it’s always among the one, first, second or third use programming languages in the world. **Gavin Henry** 00:58:00 I suppose for me, I kind of think of it like learning to speak English, you know, everything speaks C. **Jens Gustedt** 00:58:06 You’ll get by. **Gavin Henry** 00:58:07 If you can translate ideas and things from C and you can always understand what’s under the hood if you can. **Jens Gustedt** 00:58:13 Yeah. **Gavin Henry** 00:58:16 I don’t know where you hang out, you know? Can people follow you somewhere or how can they get in touch if they’ve got some questions? **Jens Gustedt** 00:58:22 I am on Mastodon. Okay, so you would easily find me there. Yeah, also LinkedIn, but I’m not very active so basically it’s Mastodon nowadays. I try not to go on too much on these commercial platforms. **Gavin Henry** 00:58:37 Thank you for coming on the show. Just as much fun as five years ago, more so. So, thanks for coming back. This is Gavin Henry for Software Engineering Radio. Thank you for listening. [End of Audio]

Is it a filesystem?

And suddenly, there may be a reverse Midas at the centre of AI’s circular economy

We introduce the Ortac/QCheck-STM, a tool to automatically generate QCheck-STM tests based on Gospel specification, in a tutorial-like manner.