2017 Make with Ada competition

[legacy]

Like companies who use MISRA? This is another way to sacrifice freedom for imaginary safety.

Yeah, "imaginary safety" which only happens in your ignorance.
I am tired to read this kind of bullshit 

[Mechatrommer]

If you read the detailed documentation about the problem, the Ada system generated an exception when the overflow occurred, which caused the system to turn off. And the programmers even identified all possible overflow problems and decided to not protect this conversion

i know! whose fault then? i bet the answer is NOT the language/ide/tool/ada, right? its the human, whoever they are... but when it comes to C, when a programmer or management BS specified to not to boundary check in memory access, and buffer overrun occured, who got the blame? you are right! C's fault, not the stupid programmer or the management BS . you see the fairness/problem here? and then what happened when a buffer overrun occured will differ from machine/OS to another. this subject requires an entire lot of discussion on it own which i will not wander into.

[gameridian]

I'm staying out of this conversation, but I will at least point out that it is more about having a comprehensive specification than it is about the language used.  Despite working with avionics systems in the past that have used jovial, pascal, and ada, I would have no issue with choosing C again.  I've worked on various aircraft subsystems such as a flight management system for a fixed wing aircraft, and modernization of a mission computer for a rotary wing aircraft, both of which were safety critical, DO-178B compliant, and written in C.  A detailed spec dominates all aspects.

[Mechatrommer]

A detailed spec dominates all aspects.

this + tolerant boss that knows rush job |= safety... in any languages...

[westfw]

Quote

Quote

Do Ada compilers like GNAT for embedded ARM manage to take advantage of that for reducing the footprint of the runtime environment, or are they still in the "the runtime is the runtime; you get the whole thing."

IMHO you should always aim to get the whole thing. A half baked runtime just sucks because one or another you have to contort yourself into all kinds of limitations.Quote

No no.   I want the whole runtime to be "available", but I want only the parts that a particular application USES to be be included in the binary.  It's something that embedded C developers more-or-less take for granted ("if you don't use printf, you won't get printf code in your .hex file"), but it's not necessarily how languages that have a significant runtime component work ("You wrote a 4 line "hello world" program in visual basic.  Don't forget to make sure that anyone who wants to run this program also downloads the 300k Visual Basic Runtime library.")
Quote

>[Ariane] This has nothing to do with Ada.I'm pretty sure I read/heard one analysis that said it would have worked fine if the overflow had simply been ignored, the way it would have been in Fortran or C.  By trapping "errors", Ada succeeded in introducing a code path that was unexpected and unhandled, while ultimately unnecessary.  Sure, it should have just handled it correctly.   But you could say that about C too.  It's a common "doublethink" in embedded programming:  "we must handle all errors so the program doesn't crash" vs "you know, the program crashing is not so bad, if it restarts quickly enough that the SYSTEM spends most of it's time working."

[NorthGuy]

Is it possible that they were not vigilant enough because they were using safe language and expected that the language provide some level of protection?

[tggzzz]

You need to understand the vital difference between "validation" and "verification"

so, in their mind ( "validation" isEqualTo "verification )

LOL 

That's the first difference they will learn in avionics.

( someone still thinks, he/she can have the same experience, mastering the difference between "validation" and "verification", by translating C sketches from Arduino into gNAT )

...and then complaining that there are more keystrokes in the Ada version, therefore it is worse.

Some people should be kept away from keyboards.

[Kalvin]

I'm staying out of this conversation, but I will at least point out that it is more about having a comprehensive specification than it is about the language used.  Despite working with avionics systems in the past that have used jovial, pascal, and ada, I would have no issue with choosing C again.  I've worked on various aircraft subsystems such as a flight management system for a fixed wing aircraft, and modernization of a mission computer for a rotary wing aircraft, both of which were safety critical, DO-178B compliant, and written in C.  A detailed spec dominates all aspects.

After that it is only a matter of time the get the product right, and then maintain the product, probably port the software into a new device, while keeping in mind that time = money. Some languages are better in this than others, though.

[tggzzz]

If you read the detailed documentation about the problem, the Ada system generated an exception when the overflow occurred, which caused the system to turn off. And the programmers even identified all possible overflow problems and decided to not protect this conversion

i know! whose fault then? i bet the answer is NOT the language/ide/tool/ada, right? its the human, whoever they are... but when it comes to C, when a programmer or management BS specified to not to boundary check in memory access, and buffer overrun occured, who got the blame? you are right! C's fault, not the stupid programmer or the management BS . you see the fairness/problem here? and then what happened when a buffer overrun occured will differ from machine/OS to another. this subject requires an entire lot of discussion on it own which i will not wander into.

Don't be silly.

A programmer that chooses to ignore warnings is at fault.
A language that cannot, by design, issue warnings is also at fault, albeit a different fault.

[Mechatrommer]

A language that cannot, by design, issue warnings is also at fault, albeit a different fault.

and then again you, as many others, cannot distinguish between a "language" and the "compiler". i'm not sure about gcc and others, but microsoft vc++ compiler is certainly gives "possible loss of data" warning when you try to assign larger to lower bit variable, and many other violations possibility too. i'm not sure which compiler you all people are refering to maybe gcc? which you are all mistakenly refering to as the "language". well, its a matter of time for someone to come up with better and more polished C/C++ compiler. its not that easy to get it 100% right when it is a free tool.

with exception to fault that can only be determined at runtime such as buffer overrun. with a good habit and experience, a simple routine may solve the issue. if one is to say this is a mcguyver or tedious babysitting job, then he should learn more, or else find another job...

Is it possible that they were not vigilant enough because they were using safe language and expected that the language provide some level of protection?

from the report, the team has done extensive test on one particular/earlier specification. the unprotected decision was a well intended decision, acceptable for the earlier case. the problem was when they moved the software to latest revision rocket that didnt obey the earlier specification. the culprit is the person/team who decided to move it without retest to new spec and redo full simulation on the new system. yeah its alot of job, programming is just a small part of it, 7bils of wasted money is too much money if its only for Ada programming. but deciding which variables to be protected or not is the babysitting job in Ada language domain. if they mourn that Ada doesnt need babysitting, the report just proved they are plain wrong;

[NorthGuy]

from the report, the team has done extensive test on one particular/earlier specification. the unprotected decision was a well intended decision, acceptable for the earlier case. the problem was when they moved the software to latest revision rocket that didnt obey the earlier specification. the culprit is the person/team who decided to move it without retest to new spec and redo full simulation on the new system. yeah its alot of job, programming is just a small part of it, 7bils of wasted money is too much money if its only for Ada programming. but deciding which variables to be protected or not is the babysitting job in Ada language domain. if they mourn that Ada doesnt need babysitting, the report just proved they are plain wrong;

I think the cause of the failure came earlier, when they failed to unit test the calculations over the entire range of the possible values for A4. It worked on A4 by pure coincidence. By the time they used it on A5 they thought it was fully tested and operational.

If I understood the report correctly, the value being calculated was not needed for the flight on that stage, and if it produced a garbage value it wouldn't be critical. The real problem was the exception caused by the overflow. The exception caused the shut-down of the entire computer which eventually caused the explosion.

The computer shutdown was meant to be a safety feature, and as it often happens with safety features, it has gone completely untested - no one ever bothered to test the scenarios with computer shutdown. Worse yet, even the commission which investigated the case didn't pointed out to the necessity of such tests. They did discuss whether shutting down the computer was a good idea or not, but they never really envisioned the consequences, never did any tests.

The exception and computer shutdown, the very features that were put there solely for safety reasons, have caused the whole thing to blow up. How ironic.

[Mechatrommer]

well, i try not to blame eng. team there a lot of people involved. i dont believe all of them are a bunch of fool and lazy either. highly suspect will be people up there who has the power to "interview" and control people and select who he like or not. who are clueless about programming details, only care about the management, economic and legislative jargons. and who only trust the advertisement. do they have report on people who got fired, sued or jailed? i believe none. in the end this people in power in regret due to the loss thought he should listen to the engineer in the first place and concluded the report with Recommendation for future project. well thats just my speculation.

[Sal Ammoniac]

Demonstrably skilled programmers do continually make many mistakes with C/C++.

That's why we do code reviews. Compilers, even very sophisticated ones, cannot catch certain kinds of logic errors, so relying on only the compiler or language is foolish.

[tggzzz]

Demonstrably skilled programmers do continually make many mistakes with C/C++.

That's why we do code reviews. Compilers, even very sophisticated ones, cannot catch certain kinds of logic errors, so relying on only the compiler or language is foolish.

Only a fool would rely on compilers to catch all errors.
Only a different kind of fool would expect code reviews to catch all errors.
Only an arrogant <expletive deleted>[1] would believe they don't need all the help they can get, from whatever source.

Code reviews are necessary but not sufficient; there are many kinds of error they will not catch. A particular problem is they are not scalable, particularly where code is produced by multiple teams/companies.

Code reviews only examine a single snapshot of a subset of the codebase. Compilers and associated tools (if permitted by the language and tools) examine the whole codebase every time they are invoked.

EDITED to ADD [1], or someone completely inexperienced in professional development projects

[nctnico]

Automated unit tests which are part of a compilation process are one of the tools which can control quality of software. Code review is just a snapshot indeed.

[Sal Ammoniac]

Automated unit tests which are part of a compilation process are one of the tools which can control quality of software. Code review is just a snapshot indeed.

They're all part of the development process, along with using static analysis tools, etc.

Code reviews are a snapshot in a sense, but a useful one. We typically catch ~95% of the bugs that would otherwise make it into verification during code reviews. All commits to our source repository are reviewed individually, which keeps the review process fine grained and less of a burden. This process may not work for all development groups, but it's been very effective for us.

[tggzzz]

Automated unit tests which are part of a compilation process are one of the tools which can control quality of software. Code review is just a snapshot indeed.

They're all part of the development process, along with using static analysis tools, etc.

Code reviews are a snapshot in a sense, but a useful one. We typically catch ~95% of the bugs that would otherwise make it into verification during code reviews. All commits to our source repository are reviewed individually, which keeps the review process fine grained and less of a burden. This process may not work for all development groups, but it's been very effective for us.

Just so. We need all the help we can get, from whatever source.

Computers are rather good at automation of dull repetitive tasks, and should be used for such. Tools that unnecessarily introduce whole classes of problems are an unwelcome distraction and waste of the most valuable resource, brainpower; avoid such tools where there are alternatives.

[legacy]

Some people should be kept away from keyboards.

Sure. My job would be easier, and less stressful.

P.s. from the C world.
I am debugging SSH (secure shell from OpenSSH). A customer(1) needs to use it in his produces, and it crashes on a "musl" roortfs (it's not glibc, it's more like uclibc, experimental, but useful on PowerPC since glibc is too bloat, and uclibc has too many problems).

Sources are a mess 

Thanks god we have debugging symbols and GDB+DDD, but I still wonder *why* they don't conform to MISRA! Debugging would be easier by ten orders of magnitude at least.



(1) Naval Engineering field. They build cruise ships's equipment.

[legacy]

Code reviews only examine a single snapshot of a subset of the codebase.

We experimented a critical failure bug during system integration test from two different teams. One was European, the other was American.

ModuleA was integrated to ModuleB.
ModuleA (EU) used meters, ModuleB (USA) used inches.

The software went into "disable channels and halt", which means "unrecoverable critical failure, mission aborted"


Another problem we had: how can you really test abnormal high critical conditions?

We had this problem on a Mach2. This kind of firmware was DO178B level A, since the airplane speed was 2500 Km/h, with a lot of low level requirements classified "critical".

if the software does something wrong with CBIT (continuous built-in test, to assure the hardware is ok, and also the software is ok), it takes longer to resume (e.g. because of an overflow in the Cordic/BKM unit? it must NOT happen) , but a delay is critical when you are moving a 2500 Km/h because it makes the airplane to go out of its trajectory, which might be critical during a mission.

We have to care about safety, and mission. Both are a must, and they must not fail.

We did a full coverage, but we tested just a subset of the abnormal high critical conditions. In my report I wrote "test is not applicable for these sub cases" (e.g. what happens if the hardware on a module gets damaged during the attack ? how will it propagate its error to the main system ? Like we have planned and tested, or in a new un-predicted way ? Will it recoverable ?)

Which is a weakness, because there are conditions in the firmware which are not fully explored in their behavior after system integration. We just know how a module reacts on test-case's inputs.

[legacy]

Automated unit tests

What do you use? Cantata? CodePurify?

[tggzzz]

Which is a weakness, because there are conditions in the firmware which are not fully explored in their behavior after system integration. We just know how a module reacts on test-case's inputs.

As I am sure you are aware (but others appear not to be), emergent behaviour is an inherent and unavoidable problem, and "you can't (unit) test quality into a product".

(My favourite example of emergent behaviour is related to sand. Nowhere in the {specification,properties} of individual grains is it {defined,measured} that sand piles will form with a half-angle of ~35 degrees)

[legacy]

As I am sure you are aware (but others appear not to be), emergent behaviour is an inherent and unavoidable problem, and "you can't (unit) test quality into a product".

That's precisely *the* point!
You can't (unit) test quality into a product!
but you have to sign the report with your blood!

Good job, ain't it? 

[GeorgeOfTheJungle]

The button "unnotify" fro this thread is not working for me, I want to unsubscribe but I can't. Any ideas, please?

[tggzzz]

As I am sure you are aware (but others appear not to be), emergent behaviour is an inherent and unavoidable problem, and "you can't (unit) test quality into a product".

That's precisely *the* point!
You can't (unit) test quality into a product!
but you have to sign the report with your blood!

Good job, ain't it? 

I rather like the (possibly apocryphal) bridge acceptance test: the architect/engineer had to stand under it as all the supporting scaffolding was being removed.

I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.

[legacy]

I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.

LOOOOOL