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.