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.
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.
For example microcontrollers or aerospace systems.
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.
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.
The good news is that this work is dying out. There isn’t a need to modernize old war birds anymore.
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.
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
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.
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.
Yes, it has the same ABI.
How do you feel about building special constructs to automatically handle these ?