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.

▲

reactordev 4 days ago | parent | next [-]

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.

▲

sureglymop 4 days ago | parent | next [-]

Maybe I misunderstand but if the process ends its entire virtual address space is gone no? Did you mean subprocess or something different?

▲

reactordev 4 days ago | parent [-]

On some OS’s

▲

loeg 4 days ago | parent | next [-]

If it isn't cleaned up by process exit, it's not really a process, is it? Just another co-routine running in the bare metal kernel or whatever.

▲

CyberDildonics 4 days ago | parent | prev [-]

Which one specifically does ending a process not clean up the memory?

▲

reactordev 4 days ago | parent [-]

Any flat memory rtos. Not everything is *nix.

For example microcontrollers or aerospace systems.

▲

CyberDildonics 4 days ago | parent | next [-]

Can you link to one that has individual virtual memory processes where the memory isn't freed? It sounds like what you're talking about is just leaking memory and processes have nothing to do with it.

▲

reactordev 4 days ago | parent [-]

virtual memory requires pages and this sucker doesn’t have them. Only a heap that you can use with heap_x.c

Everything is manual.

I get you people are trying to be cheeky and point out all modern OS’s don’t have this problem but C runs on a crap ton of other systems. Some of these “OS” are really nothing more than a coroutine from pid 0.

I have 30 years experience in this field.

▲

sph 4 days ago | parent [-]

Yeah I think I get your problem. I am prototyping a message-passing actor platform running in a flat address space, and virtual memory is the only way I can do cleanup after a process ends (by keeping track of which pages were allocated to a process and freeing them when it terminates)

Without virtual memory, I would either need to force the use of a garbage collector (which is an interesting challenge in itself to design a GC for a flat address space full of stackless coroutines), or require languages with much stricter memory semantics such as Rust so I can be safe everything is released at the end (though all languages are designed for isolated virtual memory and not even Rust might help without serious re-engineering)

Do you keep notes of these types of platforms you’re working on? Sounds fun.

	▲	reactordev 4 days ago \| parent [-]
		Not anything I can share. I’m trying to modernize these systems but man oh man was the early 80s tech brutal. Rust is something we looked into heavily and are trying to champion but bureaucracy prevents us. Flight Sims have to integrate with it in order to read/write data and it’s 1000x worse than SimConnect from MSFS. The good news is that this work is dying out. There isn’t a need to modernize old war birds anymore.

▲

flohofwoe 4 days ago | parent | prev | next [-]

Tbh on such a bare bones system I would use my own trivial arena bump allocator and only do a single malloc at startup and a single free before shutdown (if at all, because why even use the C stdlib on embedded systems instead of talking directly to the OS or hardware)

▲

mort96 4 days ago | parent | prev | next [-]

RTOSes I'm aware of call them tasks rather than processes, specifically because they don't provide the sort of isolation that a "proper" OS does.

▲

avadodin 4 days ago | parent | prev [-]

Why is something running on an rtos even able to leak memory? If your design is going to be dirty, you've got to account for that. In 30 years, I've never seen a memory leak in the wild. Set up a memory pool, memory limits, garbage collectors or just switch to an OS/language that will better handle that for you. Rust is favored among C++ users, but even Python could be a better fit for your use case.

▲

irishcoffee 4 days ago | parent | next [-]

I think the short answer is that it is very hard, time-consuming, and expensive to develop and prove out formal verification build/test toolchains.

I haven’t looked at C3 yet, but I imagine it can’t be used in a formally verified toolchain either unless the toolchain can compile the C3 bits somehow.

▲

reactordev 4 days ago | parent | prev [-]

python is not an option in this environment. Correct your tone.

▲

CyberDildonics 2 days ago | parent | next [-]

Are you really telling someone to 'correct their tone' because one of their many suggestions doesn't work on your mystery platform that you won't mention?

▲

avadodin 3 days ago | parent | prev [-]

I don't see anything wrong with my tone. I could have been snarky about it.

I provided the C solutions as well but an interpreter written in C could at least allocate objects and threads within the interpreter context and not leak memory allowing you to restart it along any services within which is apparently better than whatever framework people sharing this sentiment are using.

I'm genuinely curious. What kind of mission-critical embedded real-time design dynamically(!) allocates objects and threads and then loses track of them?

PS: On topic, I really like the decisions made in C3

▲

reactordev 3 days ago | parent [-]

ARINC-653

But no, tell me I’m wrong, tell me I’m an idiot for doing things this way, put me down for asking, and then deny my reality when I tell you.

This is why people dislike software engineers, they think they know everything.

	▲	avadodin 2 days ago \| parent [-]
		You're the only one being aggressive here. You drop a keyword and the aero-drones report. I do not mind it and I am not going to reply in kind. I have 0 experience in aerospace but reading up on ARINC-653, it appears to mandate a reasonable RT design with threads and hard slices. Even comfortable with "partitions". Where and why does the memory leak? If it is inherent in the mandated interfaces, you don't need to feel personally attacked. If it is a layer laid down by your software –whether legacy or otherwise– why can't you keep track of allocations and ownership? Unless there are 200 bytes left and all slices are accounted for and running on the edge, I feel a solution could be worked out. I wish you luck switching to Rust maybe a Rust2C translator could help.

▲

paulddraper 4 days ago | parent | prev | next [-]

> But can I still write a library in C3 and export the symbols to use in bindings?

Yes, it has the same ABI.

▲

d-lisp 4 days ago | parent | prev [-]

> dangling pointers to raw memory that [are not] cleaned

How do you feel about building special constructs to automatically handle these ?

▲

reactordev 4 days ago | parent [-]

I totally can but my gripe is about not wanting to.

▲

brabel 4 days ago | parent [-]

c3 has a @pool annotation that makes a block use an arena to allocate, that should help since all memory is freed upon exiting the block.

	▲	reactordev 4 days ago \| parent [-]
		That is dope

▲

astrange 4 days ago | parent | prev [-]

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.)

▲

flohofwoe 4 days ago | parent [-]

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).

	▲	astrange 3 days ago \| parent [-]
		> 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.