[DISCUSSION] Rationale for yet another C variant

A place of insane ideas, nothing to see here.
User avatar
Giovanni
Site Admin
Posts: 11837
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 524 times
Been thanked: 434 times
Contact:

[DISCUSSION] Rationale for yet another C variant

Postby Giovanni » Sun Dec 10, 2017 5:15 pm

Hi,

I just wanted a place to share my thoughts about systems safety and reliability. Please consider everything in this forum to be random ideas, temporary, subject to changes, subject to refinements etc, also potentially going nowhere.

After spending the best part of a day fixing this issue, it turned out to be a missing stupid cast. It does not matter the level of experience, this kind of errors are bound to creep even into the best code-bases because the C language is intrinsically non secure.

C is not the best language for embedded, it has not even been specifically designed for embedded, it is just the only the current common for embedded programming. Other newer languages often make assumptions that make them unsuitable for bare metal programming, see garbage collection or other things requiring a substantial runtime.

C has one merit: it is an high level assembler :) requiring almost nothing as runtime. This is why it is the default choice for embedded.

Let's list the most common problems we all face daily:

  1. Race conditions, when you work with asynchronous events (IRQs) this is a real issue.
  2. Overflows, especially stack overflows.
  3. Types mixing freely.
  4. Mixing pointers freely.

This is nothing new, there are coding standards like MISRA that recognize the issues and try to address them, with very partial success, using static analysis methods and restrictions on the standard C.

If a language could address the above points then most problems would be fixed or caught at compile time. Let's call this hypothetical language "Safer C".

And C++? My opinion is that:
  1. It addresses none of the above concerns, probably it introduces more.
  2. Its (growing) complexity is a safety risk in itself.
  3. Its organization tends to hide details but also problems.
  4. C is complex enough, we need something simpler and safer, enhancements should not make the language harder or unsafer.

Please don't reply to topics marked with [NO REPLY], open new topics on specific points prefixing them with [DISCUSSION]. Ideas or changes will be integrated after the discussion.

Giovanni

User avatar
Korken
Posts: 270
Joined: Wed Apr 02, 2014 4:09 pm
Location: Luleå, Sweden
Has thanked: 5 times
Been thanked: 6 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Korken » Tue Dec 12, 2017 5:18 pm

Hi Giovanni!

You have hit very close to home on me here :) As this is my general aim and has been for a while.
With the list you presented, all can be solved using C++ (I bet you saw that coming when I am writing :lol: ), lets have a look and I hope for a healthy discussion!

1. Race conditions, when you work with asynchronous events (IRQs) this is a real issue.
This is the issue and I have been working on the solution for this.
What I have created is a "compile-time reactive operating system" that by using meta-programming in C++ calculates the IRQ dependencies at compile time and guarantees deadlock free, data race free and race condition free execution between IRQs, while only adding a few instructions.
This comes from the compile time creation of the kernel and all code is embedded into the user code, so when the compilation is done, there is no operating system anymore - it has configured the IRQ hardware + some instrumentation instructions. Making the software extremely small and fast (I dare anyone to beat its speed, even with handwritten code)!
This works based on an event model (all jobs run to finish in finite time), rather than a threading model, which in my opinion models MCU system a lot better. But a threading model can be emulated by having events queuing themselves.

If this interests you, have a look here: https://github.com/korken89/crect
I will be presenting this idea at the Embedded C++ conference in Bochum, Germany (http://www.embo.io)

2. Overflows, especially stack overflows.
This one is difficult, but if one does not follow the "thread model", as in what I discussed earlier, it allows for static analysis as there are no forever loops in the same sense thanks to the fact that all jobs run to finish in finite time.
But more work in this area is a heavy research area where symbolic instrumentation is being looked into by a group at our university (based on Klee).
I'm not very much into static analysis myself though.

3. Types mixing freely. 4. Mixing pointers freely.
This is directly solved by the strong type system of C++ and its zero cost abstractions.
For example, we can make a class (with zero overhead) that encapsulates a pointer and gives guarantees on conversions.
The same can be done for types, a good example is https://github.com/foonathan/type_safe
No need for worrying about casts any more, the compiler will tell you when you have made a wrong assumption.

Please come with your, or anyones', thoughts! :)

Best Regards
Emil

User avatar
Giovanni
Site Admin
Posts: 11837
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 524 times
Been thanked: 434 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Giovanni » Tue Dec 12, 2017 7:47 pm

Interesting work.

I think the idea is a bit different, while you created a framework where race conditions are detected, my idea is to create a language C variant where race conditions become impossible unless doing willing tricks. Additionally the language would incorporate several restrictions usually enforced by coding standard like MISRA, C++ would not prevent you doing dirty things, the idea about Stronger C is that it enforces correct behaviour.

For example, where you suggest to encapsulate pointers to make them safe, in Stronger C you simply you are not allowed to mix.
Building on top of C or C++ would not change this, the potential for sloppy coding, ignorance or subtle errors is still there.

The idea is to create something inherently safer than C and C++ while still being close enough to the metal and doing this with no runtime support, statically at compile time.

Additionally, the language would not impose the use of any specific framework, or RTOS. It could work well doing bare metal programming but it could work on top of an RTOS, not ChibiOS specifically. Critical zones could manipulate interrupts or use RTOS-provided primitives, no need to marry a specific piece of SW.

Anyway, it is not finished, there are missing parts in what I posted, I will integrate in next days.

Giovanni

rvense
Posts: 2
Joined: Wed Sep 02, 2015 1:09 pm

Re: [DISCUSSION] Rationale for yet another C variant

Postby rvense » Tue Dec 12, 2017 10:23 pm

Can I ask if you're familiar with Rust at all? It is supposedly quite suitable for embedded work and has a thriving ecosystem and mature toolchain.

User avatar
Giovanni
Site Admin
Posts: 11837
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 524 times
Been thanked: 434 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Giovanni » Tue Dec 12, 2017 10:37 pm

Hi,

I am not very familiar with rust, I think it relies on some form of memory allocation even if it does not have garbage collection, am I right?

Embedded requires static allocation, several standards forbid run time allocation entirely. The whole point in using C is that it does not rely on anything, can be used "naked".

Anyway, type safety and boundaries are only part of the problems, the main problem is making a synchronous world to interact safely with an asynchronous one. This is what both Stronger C and what Korken proposed are about.

Giovanni

User avatar
Korken
Posts: 270
Joined: Wed Apr 02, 2014 4:09 pm
Location: Luleå, Sweden
Has thanked: 5 times
Been thanked: 6 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Korken » Thu Dec 14, 2017 10:25 am

Giovanni wrote:I think the idea is a bit different, while you created a framework where race conditions are detected, my idea is to create a language C variant where race conditions become impossible unless doing willing tricks. Additionally the language would incorporate several restrictions usually enforced by coding standard like MISRA, C++ would not prevent you doing dirty things, the idea about Stronger C is that it enforces correct behaviour

Ah no, you have misunderstood. It does not detect, it guarantees.
Unless you do willing tricks to trick it, it guarantees :)

The only thing it does not detect during compile time is if you are going through function calls and take a resource.
For this I have a "debug mode" which adds another 3-5 instrumentation instructions to a lock, which checks that all guarantees are held (this is currently under development and is being added now, you can follow this here https://github.com/korken89/crect/issues/2).


State-machines:
I saw in your other post, you are writing about a state machine language. This also already exists in C++, and I use it in my embedded projects.
I cannot beat its speed with hand written code as well. :) Have a look, it is currently under review to be added to boost, but it is a single header library.
And it generates the state machine at compile-time by translating UML specifications.
Link: https://github.com/boost-experimental/sml


RUST:
Rust has a lot of interesting properties, but does not solve it all. There are no requirements on garbage collection nor dynamic memory allocation, just to straighten that out.
If you want an overview of RUST in embedded our embedded systems group have done a lot of work there and you can check this guy out: https://github.com/japaric
In my opinion, I think that in 5-10 years RUST will take over a lot in the embedded space unless C++ adds a few parts to compete, but for now it is not well tested for production code (in embedded) and is very new. The embedded parts are still based on experimental features in the language.

User avatar
Giovanni
Site Admin
Posts: 11837
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 524 times
Been thanked: 434 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Giovanni » Thu Dec 14, 2017 11:33 am

Korken wrote:The only thing it does not detect during compile time is if you are going through function calls and take a resource.
For this I have a "debug mode" which adds another 3-5 instrumentation instructions to a lock, which checks that all guarantees are held


In the scheme I proposed you cannot hide accesses using functions (local or external does not matter) and there are no added instructions, it is a pure static compile time enforcement.

About state machines, there are plenty generators, the idea is that a language designed for embedded could have that as a construct. Note that critical sections and state machines go together, often state machines are accessed from asynchronous context so have to be handled from critical sections.

I understand that things taken separately already exists, probably in multiple forms and implementations, again, the idea is to have a language -for embedded- inherently safer than C.

I can list some of my own requirements for such a thing:

- No runtime required, 1:1 code generation, what you write is what you get without mysterious blobs added by libraries. This is the best quality of C and should be kept.
- No allocation required.
- Rules enforced.
- Strong types checking. No promotion, no implicit casts, no implicit truncation.
- Pointers safety. Casts only allowed on "compatible" types, other casts simply rejected.
- Handling of interactions between asynchronous and synchronous worlds using critical zones.
- Not enforcing how critical zones are implemented, it could be interrupts disable, spin-lock variables with multiple cores, mutexes between RTOS tasks or all of them together. The language just tracks interactions and enforces correct access to resources, the "how" is not part of the language.
- Very basic OOP.
- Close to C unless changes are required to implement above points or for safety in general.
- State machines... not even strictly required but nice to have integrated in the language, no need for tools, extra build steps, generated code not compliant with style guides or coding rules (see MISRA).

Right now I am not even specifying things seriously, just writing down ideas.

I don't know much about Rust but my understanding is that it relies on memory allocation (not garbage collected), I will give a look to those embedded extensions but "extension" makes me think it has not been designed with embedded in mind, just adapted.

Giovanni

User avatar
Korken
Posts: 270
Joined: Wed Apr 02, 2014 4:09 pm
Location: Luleå, Sweden
Has thanked: 5 times
Been thanked: 6 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Korken » Thu Dec 14, 2017 12:23 pm

I see your point Giovanni, I think my main point is that we should not create a language (or language features) for what can be solved with libraries. It's also the core philosophy of C++, which I tend to agree with a lot.

For example, a simple tool could be made that does static analysis of the code to check if "forbidden" parts of a language is used.
Or a sanitizer/static checker could be added to Clang that does the checks.

Of course these are my opinions, and, I and a few colleagues were down the road of creating a language for embedded (you can have a look at this here: https://rtfm.codeplex.com/ ) but in the end it was realized that the addition the language gave did not weigh up for the development time and what we could do in other languages with a bit of tooling instead.

User avatar
Giovanni
Site Admin
Posts: 11837
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 524 times
Been thanked: 434 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Giovanni » Thu Dec 14, 2017 1:27 pm

Sorry to hear that you had no success with that effort.

Giovanni

User avatar
Korken
Posts: 270
Joined: Wed Apr 02, 2014 4:09 pm
Location: Luleå, Sweden
Has thanked: 5 times
Been thanked: 6 times
Contact:

Re: [DISCUSSION] Rationale for yet another C variant

Postby Korken » Sun Dec 17, 2017 10:24 pm

It was partially successful, but more importantly it was an eye-opener. :)
The language itself was working as expected but a pain to extend and maintain.

The embedded group at our uni then went to Rust, and are doing great work there, and have a version of crect for rust as well.
While I (being part of the robotics group) went to C++ and did what I could there, and none of us really saw the need for making our own language after that.
Especially in what Rust will give, though being experimental now, shows great promise and with them joining it they have the power to sway the language and get the features they want for embedded.


Return to “Safer C”

Who is online

Users browsing this forum: No registered users and 0 guests