A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love.
You could do the same thing as part of compiling to WebAssembly; the recently-issued Wasm 3.0 specification comes with support for multiple memory spaces in one WebAssembly module, so memory segment boundaries can be meaningfully enforced within a single C program, similar to what happens in Fil-C (and other technologies such as CHERI).
C++: "look at what others must do to mimic a fraction of my power"
This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.
> I'm baffled as to why you would want to use macros to emulate c++.
I like the power of destructors (auto cleanup) and templates (generic containers). But I also want a language that I can parse. Like, at all.
C is pretty easy to parse. Quite a few annoying corner cases, some context sensitive stuff, but still pretty workable. C++ on the other hand? It’s mostly pick a frontend or the highway.
It's interesting to me to see how easily you can reach a much safer C without adding _everything_ from C++ as a toy project. I really enjoyed the read!
Though yes, you should probably just write C-like C++ at that point, and the result sum types used made me chuckle in that regard because they were added with C++17. This person REALLY wants modern CPP features..
Given how C was seen in the past, before there was a change of heart to add C11/C17, minus atomics and aligned memory allocators (still between experimental or not going to happen),
How can anyone be this interested in maintaining an annex k implementation when it's widely regarded as a design failure, specially the global constraint handler. There's a reason why most C toolchains don't support it.
Nice toy. It works until it stops working. An experienced C developer would quickly find a bunch of corner cases where this just doesn't work.
Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?
Yeah, kids like to waste time to make C more safe or bring C++ features.
If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases.
If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return.
Temporary buffers? if they arent big, dont be afraid to use static char buf[64];
No need to waste time for malloc() and free. They are big? preallocate early and reallocate or work on chunk sizes. Simple and effective.
God forbid we should make it easier to maintain the existing enormous C code base we’re saddled with, or give devs new optional ways to avoid specific footguns.
Goofy platform specific cleanup and smart pointer macros published in a brand new library would almost certainly not fly in almost any "existing enormous C code base". Also the industry has had a "new optional ways to avoid specific footguns" for decades, it's called using a memory safe language with a C ffi.
I consider code written in Frama-C as a verifiable C dialect, like SPARK is to Ada, rather than C proper. I find it funny how standard C is an undefined-behaviour minefield with few redeeming qualities, but it gets some of the best formal verification tools around.
A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love.
https://news.ycombinator.com/item?id=45133938
https://fil-c.org/
You could do the same thing as part of compiling to WebAssembly; the recently-issued Wasm 3.0 specification comes with support for multiple memory spaces in one WebAssembly module, so memory segment boundaries can be meaningfully enforced within a single C program, similar to what happens in Fil-C (and other technologies such as CHERI).
> C23 gave us [[cleanup]] attributes
C23 didn't introduce it, it's still a GCC extension that needs to be spelled as [[gnu::cleanup()]] https://godbolt.org/z/Gsz9hs7TE
C++: "look at what others must do to mimic a fraction of my power"
This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.
> I'm baffled as to why you would want to use macros to emulate c++.
I like the power of destructors (auto cleanup) and templates (generic containers). But I also want a language that I can parse. Like, at all.
C is pretty easy to parse. Quite a few annoying corner cases, some context sensitive stuff, but still pretty workable. C++ on the other hand? It’s mostly pick a frontend or the highway.
It's interesting to me to see how easily you can reach a much safer C without adding _everything_ from C++ as a toy project. I really enjoyed the read!
Though yes, you should probably just write C-like C++ at that point, and the result sum types used made me chuckle in that regard because they were added with C++17. This person REALLY wants modern CPP features..
Perhaps but a project using this stops you from writing any old C++ in your C. Writing C++ in a C style has no such protection.
It's choosing which features are allowed in.
I checked Fil-C out and it looks great. How is this different from Fil-C? Apart from the obvious LLVM stuff
Any hopes that MSVC will add C23 support before 2040?
Given how C was seen in the past, before there was a change of heart to add C11/C17, minus atomics and aligned memory allocators (still between experimental or not going to happen),
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual...
https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp...
And the new guidelines regarding the use of unsafe languages at Microsoft, I wouldn't bet waiting that it will ever happen, even after 2040.
https://azure.microsoft.com/en-us/blog/microsoft-azure-secur...
https://blogs.windows.com/windowsexperience/2024/11/19/windo...
Will windows be relevant by 2040? I personally don’t think so.
Depends on how much Valve manages to get rid of Proton.
Bit of a random question on an article about C.
Just don't mix that up with the real safec.h header from safeclib:
https://github.com/rurban/safeclib/tree/master/include
How can anyone be this interested in maintaining an annex k implementation when it's widely regarded as a design failure, specially the global constraint handler. There's a reason why most C toolchains don't support it.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm
Nice toy. It works until it stops working. An experienced C developer would quickly find a bunch of corner cases where this just doesn't work.
Given how simple examples in this blog post are, I ask myself, why don't we already have something like that as a part of the standard instead of a bunch of one-off personal, bug-ridden implementations?
It would be a lot more constructive if you reported a bunch of corner cases where this doesn't work rather than just dismissing this as a toy.
Yeah, kids like to waste time to make C more safe or bring C++ features. If you need them, use C++ or different language. Those examples make code look ugly and you are right, the corner cases.
If you need to cleanup stuff on early return paths, use goto.. Its nothing wrong with it, jump to end when you do all the cleanup and return. Temporary buffers? if they arent big, dont be afraid to use static char buf[64]; No need to waste time for malloc() and free. They are big? preallocate early and reallocate or work on chunk sizes. Simple and effective.
Can you share such a corner case?
God forbid we should make it easier to maintain the existing enormous C code base we’re saddled with, or give devs new optional ways to avoid specific footguns.
Goofy platform specific cleanup and smart pointer macros published in a brand new library would almost certainly not fly in almost any "existing enormous C code base". Also the industry has had a "new optional ways to avoid specific footguns" for decades, it's called using a memory safe language with a C ffi.
I don't understand this passion for turning C into what it's not...
Just don't use C for sending astronauts in space. Simple.
C wasn't designed to be safe, it was designed so you don't have to write in assembly.
Just a quick look through this and it just shows one thing: someone else's walled garden of hell.
> Just don't use C for sending astronauts in space. Simple.
Last time I checked, even SpaceX uses C to send astronauts to space...
> Just don't use C for sending astronauts in space
But do use C to control nuclear reactors https://list.cea.fr/en/page/frama-c/
It's a lot easier to catch errors of omission in C than it is to catch unintended implicit behavior in C++.
I consider code written in Frama-C as a verifiable C dialect, like SPARK is to Ada, rather than C proper. I find it funny how standard C is an undefined-behaviour minefield with few redeeming qualities, but it gets some of the best formal verification tools around.
Some C devs will make all kinds of crazy efforts only not to use C++.
Actually C performs quite good in exactly that area.
https://ntrs.nasa.gov/citations/19950022400