Comment by Fiveplus
3 days ago
I've been following C3 for sometime now, and I really appreciate the discipline in the design philosophy here.
Neither does it force a new memory model on you, nor does it try to be C++. The killer feature for me is the full ABI compatibility. The fact that I no longer have to write bindings and can just mix C3 files into my existing C build system reduces the friction to near zero.
Kudos to the maintainer for sticking to the evolution, not revolution vision. If you are looking for a weekend language to learn that doesn't require resetting your brain but feels more modern than C99, I highly recommend giving this a shot. Great work by the team.
But can I still write a library in C3 and export the symbols to use in bindings?
The only thing stopping me from just going full C the rest of my career is cstrings and dangling pointers to raw memory that isn’t cleaned up when the process ends.
Maybe I misunderstand but if the process ends its entire virtual address space is gone no? Did you mean subprocess or something different?
On some OS’s
16 replies →
> But can I still write a library in C3 and export the symbols to use in bindings?
Yes, it has the same ABI.
> dangling pointers to raw memory that [are not] cleaned
How do you feel about building special constructs to automatically handle these ?
I totally can but my gripe is about not wanting to.
2 replies →
Is full ABI compatibility important? I'm having a hard time seeing why.
I mean… C isn't even an unsafe language. It's just that C implementations and ABIs are unsafe. Some fat pointers, less insanely unsafe varargs implementations, UBSan on by default, MTE… soon you're doing pretty well! (Exceptions apply.)
How would you integrate C3 with other programming languages (not just C), or even talk to operating systems if you don't implement a common ABI?
And the various system ABIs supported by C compilers are the defacto standards for that (contrary to popular belief there is no such thing as a "C ABI" - those ABIs are commonly defined by OS and CPU vendors, C compilers need to implement those ABIs just like any other compiler toolchain if they want to talk to operating system interfaces or call into libraries compiled with different compilers from different languages).
> How would you integrate C3 with other programming languages (not just C)
That's the job of an FFI. The internal ABI of most languages isn't anything like their FFI, eg any garbage collected language can't use the OS "C" ABI.
Most operating systems don't use the same ABI for kernel syscalls and userland libraries either. (Darwin is an exception where you do have to link a library instead of making syscalls yourself.)
> contrary to popular belief there is no such thing as a "C ABI"
It is a "C ABI" if it has eg null-terminated strings and varargs with no way to do bounds checking.