3 ms·

> In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882 Noti

> In the case of C or C++, that usually means (among other things) demonstrating compliance with an accepted published standard like ISO 8859 or ISO 14882 Notice that the C++ standard has dozens of open bugs, some of them are actually due to incompatibilities within the standard itself, e.g., because it require implementations to comply to two different things simultaneously, but these are incompatible with each other. So in practice, it is impossible for any C++ compiler to actually comply to the spec. So at the end the only thing any process ends up looking at, is that your compiler has lots of tests, and the process of developing it: do all tests have to pass before each release? etc. Once such a test suite is verified, it becomes somethings others can use to say "my compiler passes it", but in practice, these test suites have bugs, and the test suites of gcc and clang are more comprehensive etc. Even if your compiler passes one such test suite, it won't pass certification if you don't have version control, testing running regularly, etc. The rust compiler has a huge test suite. Every single change to the compiler must pass the test suite on some of the supported architectures, new releases of the compiler are tested against all the tests of the 40.000 libraries available in crates.io to make sure results don't change in code people actually write, etc. > Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. This has been trivial to do in our experience. Just pay the fees. The standard at which the Rust toolchain development operates is much higher than what the highest safety certifications require, because the safety of these certifications is actually very low: their whole purpose is to avoid liability, so most of them are just a way to create a paper trail that shows that your process is not complete trash, so that if someone sues you, you can say that you were operating at the highest standards. Nothing more, nothing less. Nobody is interested in making these standards "good", that's not their purpose. Practically, the only issue is that some certifications require you to certify every toolchain you want to use. So if you bump the stable Rust toolchain version from say 1.49 to 1.50, you need to re-certify. The process for recertifying is quick, since nothing covered during the certification process actually changed, but you have to pay the fees again and again and again. I think this is braindead, but AFAIK all compilers for all languages have this problem.

Argorak 5y ago
What people generally mistake is that compilers are not certified - they are qualified tools. In this case, the regulators check if the vendor of the compiler uphold certain standards and practices - once. After that, you - the vendor - are allowed to update yourself. https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/ btw. is our effort to ship rustc with proper support required by most players in the industry.
bregma 5y ago
>> Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. > This has been trivial to do in our experience. Just pay the fees. Ah, MAX-8 syndrome. Just pay someone off and your airplane will be just fine. The safety auditors I deal with are little more rigourous. > The process for recertifying is quick, since nothing covered during the certification process actually changed, but you have to pay the fees again and again and again. I produce a qualified toolchain for a living. The qualification process for the toolchain itself is fairly simple: re-run all of the qualifying test suites (a process that takes maybe a week of elapsed time), analyse all of the results, and dispose of each and every new or unexpected result, a process that can take several elapsed weeks. The runtimes have to be certified: this requires additional tests to produce more evidence of 100% MC/DC coverage and faulty injection. The paperwork then has to be prepared, reviewed, and submitted. All in all a couple of full-time-engineer equivalent years. Once the auditors have given their stamp of approval, the toolchain can not change. Period. We produce a safety-certified version of our OS and its SDK every two years or so, not because the auditor fees are high, but because it's a massive amount of work because people's lives are at stake, and the price of the loss of one life is just too damn high. But go ahead and pay the right people off to sneak something by. Chances are good the people responsible will have moved on to damage something else by the time the corpses start piling up.
- volta83 5y ago
  Can you summarize your claim ? AFAICT, you are trying to say that current standardized certification processes aren't rigorous enough, and that you should be doing more. I agree 100%, this is why we are using Rust, seL4, etc. No one requires us to do this, but our projects using Rust have less bugs and issues than our past projects using C and C++.

Argorak 5y ago

What people generally mistake is that compilers are not certified - they are qualified tools. In this case, the regulators check if the vendor of the compiler uphold certain standards and practices - once. After that, you - the vendor - are allowed to update yourself. https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/ btw. is our effort to ship rustc with proper support required by most players in the industry.

bregma 5y ago

>> Trivially true, but it will be a challenge to convince your auditors that that is a reasonable safety story. > This has been trivial to do in our experience. Just pay the fees. Ah, MAX-8 syndrome. Just pay someone off and your airplane will be just fine. The safety auditors I deal with are little more rigourous. > The process for recertifying is quick, since nothing covered during the certification process actually changed, but you have to pay the fees again and again and again. I produce a qualified toolchain for a living. The qualification process for the toolchain itself is fairly simple: re-run all of the qualifying test suites (a process that takes maybe a week of elapsed time), analyse all of the results, and dispose of each and every new or unexpected result, a process that can take several elapsed weeks. The runtimes have to be certified: this requires additional tests to produce more evidence of 100% MC/DC coverage and faulty injection. The paperwork then has to be prepared, reviewed, and submitted. All in all a couple of full-time-engineer equivalent years. Once the auditors have given their stamp of approval, the toolchain can not change. Period. We produce a safety-certified version of our OS and its SDK every two years or so, not because the auditor fees are high, but because it's a massive amount of work because people's lives are at stake, and the price of the loss of one life is just too damn high. But go ahead and pay the right people off to sneak something by. Chances are good the people responsible will have moved on to damage something else by the time the corpses start piling up.

volta83 5y ago
Can you summarize your claim ? AFAICT, you are trying to say that current standardized certification processes aren't rigorous enough, and that you should be doing more. I agree 100%, this is why we are using Rust, seL4, etc. No one requires us to do this, but our projects using Rust have less bugs and issues than our past projects using C and C++.