So if one finally manages to get a safer C variant that finally wins the hearts of UNIX kernels and embedded devs, it is a win for all, even those that don't care about C on their daily work.
Until it happens, that lower layer all IoT devices and cloud machines will be kept in C, and not all of them will be getting security updates.
I'm going to strongly disagree with that statement.
As far as I'm aware, one of the very few toolchains that even try to improve on this over C are Ada/SPARK.
Global mutable state is marked as Unsafe in Rust.
> nor will it make subsystem supervision work correctly
Erlang is built specifically around this concept.
Perfect is the enemy of good here, throwing out a whole language due to one case doesn't help anyone.
It's also the simplest way to avoid dynamic allocation and the associated OOM issues. So, short of doing static analysis to bound heap usage at compile time, that makes things worse.
And Toyota already got the static analysis wrong for their stack usage. At least globals will fail to compile if they won't fit.
[0] https://www.transportation.gov/briefing-room/us-department-t...
Oh dear no. Certainly not.
Read https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...
My favourite part from is, "Watchdog kicked by a hardware timer service routine".
A watchdog timer is a piece of hardware that decrements a counter every microsecond or similar. The control system's main loop, running on the CPU, "kicks" the watchdog by setting the counter to a value like 1000 each iteration. The result is that if the CPU fails to execute the main loop often enough, the watchdog will "fire". This a) tells you that you have a bug and b) typically reboots the system so it has a chance to recover.
Toyota used a timer service routine to kick the watchdog. This defeats the purpose of the watchdog. The control software can happily get stuck or crash and the watchdog will not notice. The fact that an engineer added this "feature" tells you that the watchdog was firing in development. That should have been addressed by fixing the buggy software, not by disabling the test.
The fact that the disabled watchdog made it into the production release is unforgivable.
That wasn't the final word, though. I believe this is what the GP was referring to:
> When NASA software engineers evaluated parts of Toyota’s source code during their NHTSA contracted review in 2010, they checked 35 of the MISRA-C rules against the parts of the Toyota source to which they had access and found 7,134 violations. Barr checked the source code against MISRA’s 2004 edition and found 81,514 violations.
...
> Their descriptions of the incredible complexity of Toyota’s software also explain why NHTSA has reacted the way it has and why NASA never found a flaw it could connect to a Toyota’s engine going to a wide open throttle, ignoring the driver’s commands to stop and not set a diagnostic trouble code. For one, Barr testified, the NASA engineers were time limited, and did not have access to all of the source code. They relied on Toyota’s representations – and in some cases, Toyota misled NASA.
http://www.safetyresearch.net/blog/articles/toyota-unintende...
<quote>
Spirit of C:
a. Trust the programmer.
b. Do not prevent the programmer from doing what needs to be done.
c. Keep the language small and simple.
d. Provide only one way to do an operation.
e. Make it fast, even if it is not guaranteed to be portable.
The C programming language serves a variety of markets including safety-critical systems and secure systems.
While advantageous for system level programming, facets (a) and (b) can be problematic for safety and security.
Consequently, the C11 revision added a new facet:
=> f. Make support for safety and security demonstrable.
</quote>
I think the only successful "subset of C" is MISRA.
For C programs, one strategy is to provide a set of macros to be used as replacements for unsafe types in variable declarations. These macros will allow you, with a compile-time directive, to switch between using the original unsafe C elements, or the compatible safe substitutes (which are C++ and require a C++ compiler).
The replacement of unsafe C types with the compatible substitute macros can be largely automated, and there is actually a nascent auto-translator[2] in the works. (Well, it's being a bit neglected at the moment :)
Custom conventions using macros to improve code quality are not that uncommon in organized C projects. Right? But this one can (optionally, theoretically) deliver complete memory safety. So you might imagine, for example, a linux distribution providing two build versions, where one is a little slower but memory safe.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.559...
It can compile small enough to run on an Arduino: https://github.com/stepcut/idris-blink
Other OSes not tied to UNIX culture were always more open to reach out for C++, even if constrained to a certain subset.
http://www.l4ka.org/projects/pistachio/pistachio-whitepaper....
I can see your point if you're saying compiler use lets them avoid a language they just dont want to use. Which they couldnt if using it for an OS.
OS X and its descendents is the only exception.
Which goes back to NeXTSTEP using Objective-C and offering UNIX compatibility only as a path to bring software into the system, battling against SGI and Sun market space.
I don’t necessarily think it would, but if it did, those would all be reasons
There's also some really neat language-level concurrency support; work is ongoing on new features and a shorter summary, but you can see one of our Master's student theses for details: https://uwspace.uwaterloo.ca/handle/10012/12888
While C does have longjmp and friends, usage of them is hardly idiomatic, so most C code assumes no non-local tranfer of control happens when calling functions. Coding with non-local transfer of control and without require very different idioms.
C++ was a C variant once.
It doesn't require them/us to change much, just add these flags and the compiler will warn you about things that are unsafe.
I've always found it quite sad that no one is interested in bettering C enough to push relevant changes through.
Only newbies make memory corruption errors.
Yet even Dennis acknowledged correct code mattered, and Johnson created lint in 1979!
Largely ignored until clang and its analyzers came into the scene.
Although it's more along the lines of Plan9 - a unix-like system that ignores the bits of POSIX that really suck.
Also how would you make memcpy() safe in a POSIX implementation on Redox?
So it says Not Unix right on th tin.
Easy, don't have memcpy().
Something akin to Intel MPX.
Now will they in this.
A safer variant wouldn't be C. What makes C great for OS development is that it is just a step above assembly and you as a developer are given tremendous amount of power to do good and evil. C#/Java are programming languages with training wheels and it's great for application development. But for low level coding required for OS, network stacks, databases, etc, you really have to take the training wheels off.
I suppose you can try and make the C type system more stringent, but then it wouldn't be C. And considering they are aiming for backwards compatibility with existing C and its immense code infrastructure, they will have to keep the "flaws" in c for all.
Time would be better spent making the libraries/kernel/etc sturdier but if they can pull it off and win the hearts and minds of OS developers, then so be it.
Also, people have been trying to sideline C for decades. Each attempt has only reinforced C's standing and reminded us why C is so essential for OS development. Anyone remember the ill-fated attempt by Sun with their JVM centered JavaOS?
I can switch to 4.6, but don't want the risk of an experimental feature yet.
Google is using languages with training wheels to write core components of Fucshia (TCP/IP stack and file system tools are written in Go), as well as the new Android GPU debugger (also in Go).