Home > On-Demand Archives > Talks >
Preparing for the Future of Embedded C Programming: An Overview of the Upcoming ISO/IEC 9899:2023 C Standard
Niall Cooling - Watch Now - Duration: 46:04
The ISO/IEC 9899:2023 C programming standard (C23) has been finalised and is set to release in the near future, and it is expected to bring several changes and improvements to the language. This talk is specifically aimed at embedded C programmers, who will benefit from understanding the changes in the upcoming standard.
The talk will begin by providing an overview of the significant changes and improvements that the new standard will introduce (with a quick review of C11 and C18) of interest to the embedded programmer. Many changes include an aim to “harmonize” with modern C++ and improve code interoperability. The presentation will also cover the potential challenges and issues that embedded C programmers may face when migrating to the new standard. This will include an overview of the potential compatibility issues and the need to update existing code and development practices.
The talk will conclude by highlighting the benefits that embedded C programmers can expect from adopting the new standard, including increased reliability, and reduced development time and costs.
The overall goal of the presentation is to provide embedded C programmers with a comprehensive understanding of the upcoming changes to the C programming language and how it will impact their work.
Thanks for the comment.
You’re correct, auto was originally used to indicate to the compiler you wanted a block scoped object on the stack. As opposed to the keyword register (meaning is obvious). Both are redundant (and have been for many decades) as compilers are far better than us at allocating objects to registers/stack.
I haven’t seen auto used in since I started using C (which is nearly 40 years now). The original use of auto was deprecated and has now been removed, so there is no ambiguity.
In addition, as C++ has been using auto this way for over a decade (since C++11) and we haven’t seen any issues there then I wouldn’t worry.
Regards.
I was just a little surprised. Because at the beginning of your talk you've highlighter, that authors are finally removing the K&R-style function definitions. And here we have such an ambiguity. :-) Anyway, I've never seen it in the field too. Just in the ancient books.
But "register" keyword seems still usable. I'm not a big fan of the code fine-tuning or studying the assembler listings, but highlighting one or two really "popular" variables inside a function seems still a good idea. Reduces number of the intermediate load-store instructions. At least that's what I've observed when applied it out of curiosity. That was a Cortex-M4 based project.
By the way, about "const". It is indeed confusing but not too much. As a rule of thumb, I'm using the following convention:
1) the module-scope "const" variable goes to the rom (flash);
2) the function-scope "const" variable goes to the ram;
3) the function-scope "static const" variable goes to the rom (flash);
Maybe it doesn't work for all possible cases, but GCC for ARM behaves this way.
Thank you for a very clear presentation helping to navigate the confusing waters associated with differences between versions of standards. The information you presented was very informative and useful.
Thank you for you kind comment. The feedback is really appreciated and makes supporting the EOC worthwhile.
Thanks for the talk, Niall! In discussing constexpr you mentioned a motivation being that embedded programmers would like to be able to ensure that some piece of data is stored in Flash but I didn't catch if constexpr actually guarantees that. Could you clarify that for me?
Unfortunately we don't have any guarantees as the standard works to a conceptual 'abstract machine'. There is no concept of Flash/RAM etc., only the lifetime and immutability concepts. It will depend on the allocation to the memory sections by the compiler/linker and then how we can map them to our actual memory implementation. Nevertheless, you would expect a compiler will map constexpr object to .rodata (or similar) which we can then place in Flash. So it's the same approach as current 'static const' data in C, but with better guarantees than simple 'const'. Hope that helps?
It does, thanks!
Nicely done, Niall; thank you very much for the talk. Question on 'attribute' syntax used in your slides: is the double bracket [[attrib]] syntax meant to be generic, or are the "[[" and "]]" required? (I'm thinking of gcc's __attribute__((attribute-list)) syntax--will gnu have to change?)
Hi, Thanks for the nice feedback.
The syntax (as per modern C++) is [[ attribute-list ]] where the list can be a comma separated list and is intended to be generic across all toolchains in an attempt to replace different compilers (e.g. GCC and __attribute__ etc.) and various pragma's being use for the same concept. The idea is the gnu syntax will be deprecated and replaced with the attribute specifier. The benefit of C23 adopting it is that C++ has been using it since C++11 and will help where we have mixed C and C++ (as per most embedded C++ applications). Cheers Niall.
Big thanks for you wrapped introduction to the C23. It is really a nice step forward for the embedded applications. The "#embed" seems to be an especially good feature. Because managing to integrate a binary blob into the executable using the linker is almost always a lot of pain. At least because it depends on the concrete build chain. So yes, I'm looking forward for it.
Type inference may seem a nice feature too, but I don't think it will be a ubiquitous one. It must be applied explicitly to the distinct variables and functions, so it seems easy to break a chain like. But in the certain cases it might be handy.
By the way, if I'm not wrong the original "auto" keyword meaning was something like a " variable with a local duration". Though I've never seen it actually used, aren't standard authors concerned about this ambiguity?