3 ms·
> Who exactly are these new C-standards for? An example: The C11 memory model + <stdatomic.h> + many compilers supporting C11 has/had a positive impact on lang
by acuozzo 4y ago
> Who exactly are these new C-standards for?
An example: The C11 memory model + <stdatomic.h> + many compilers supporting C11 has/had a positive impact on language runtimes. Portable CAS!
> If your team is up-to-date enough to quickly adopt C23, then why not just use Rust or (heaven forbid, C++23)?
Another example: If you're programming e.g. non-internet-connected atomic clocks with weather sensors like those produced by La Crosse, then there's no real security model to define, so retraining an entire team to use Rust wouldn't make much sense. (And, yes, I know that Rust brings with it more than just memory safety, but the semantic overhead comes at a cost.)
Another example: Writing the firmware to drive an ADC and broker communication with an OS driver.
Another example: The next Furby!
- attractivechaos 4y agoAtomic is one of the few things in C11 I like most. Unfortunately, it is an optional feature along with threading [1]. It is not portable. In the end, I am still using gcc/clang's __sync or __atomic builtins. [1] https://en.wikipedia.org/wiki/C11_(C_standard_revision)#Optional_features https://en.wikipedia.org/wiki/C11_(C_standard_revision)#Opti...
- fweimer 4y ago<stdatomic.h> is provided by GCC (not the libc), so I expect it to be available everywhere the atomic builtins are supported. I prefer the builtins. With _Atomic you can easily get seq-cst behavior by mistake, and the <stdatomic.h> interfaces are strictly speaking only valid for _Atomic types.
- acuozzo 4y ago> Unfortunately, it is an optional feature along with threading [1]. It is not portable. Portability isn't binary. It's the result of work being done behind-the-scenes to provide support for a common construct on a variety of hardware and operating systems. It's a spectrum. GCC certainly is portable, but it doesn't support every ISA and OS. Over time it has even dropped support for several. Random thoughts since I'm still in the process of waking up… 1. Most of <stdint.h> is optional 2. long is 64 bits on Tru64 Unix which is valid under all versions of the standard
- kazinator 4y agoRequiring C11 is itself a portability issue. I can easily whip up CAS for all platforms I care about, plus a few more for bonus, using nothing but C99 or C90 (and have actually done it before). Possibly, without even using any language extensions, unless I want the operations inlined.
- MaxBarraclough 4y agoDid you manage to write a truly portable compare-and-swap in standard C? Or did the code just happen to seem to work on your platform? I'd be surprised if the former were possible. From a quick web search, C doesn't even give you the guarantees necessary for Peterson's Algorithm, [0][1] and volatile doesn't help. [2][3] [0] https://codereview.stackexchange.com/a/124683 https://codereview.stackexchange.com/a/124683 [1] https://stackoverflow.com/questions/35527557/errors-with-petersons-algorithm#comment58774142_35528276 https://stackoverflow.com/questions/35527557/errors-with-pet... [2] https://web.archive.org/web/20160525000152/https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/ https://web.archive.org/web/20160525000152/https://software.... [3] https://old.reddit.com/r/programming/comments/d457c/volatile_almost_useless_for_multithreaded/c0xfxdv/ https://old.reddit.com/r/programming/comments/d457c/volatile...
- vbtemp 4y agoI think the point by kazinator still stands. C11 is still a portability issue (which was the root of my original question above). ANSI C is the de-facto baseline everything has in common, using C11+ narrows which platforms you're able to build for. Even if C11 does provide the primitives for correct implementation of Peterson's Algorithm, what about the other platforms that don't have a C11 compiler - it does them no good. As to the point more directly, a lot of the C code I've seen is for real time and embedded systems that are usually time and memory partitioned, and do not have the same concerns regarding concurrency. I guess if I could rephrase my original question: People who are going to adopt C23 - who are you and what field/industry/line-of-work are you in? Asking because in my line-of-work, C is ubiquitous and I personally love coding in C, but anything beyond ANSI C (or C99) is "cool" but undermines the point of C as I've used it, which is its use cross-platform for a huge set of common and uncommon architectures and instruction sets. If something only needs to run on common, conventional platforms, C, however much I love it, would no longer necessarily be a strong contender in light of many alternatives. It seems like these standards target an ever shrinking audience (much smaller than the whole universe of software developers working in C).