engineering ethics (it was [SOLVED] funny CC)

[richardman]

If the short-circuit evaluation is to be avoided, then the correct behavior for any coverage tools is to diagnose the use of the && and || operators as unsafe, NOT by requiring compiler changes.

[tggzzz]

the "quality" implies how deep you know what your source code does...

Quality requires far more than that, of course.

Lastly, you have to create something that solves the client's problem.

Firstly, and far more intractably, you have to get the client to understand their problem and provide a sufficient specification of the problem.

[grumpydoc]

The things which C is good at occasionally  require flexibility in the type system.

ummm 

Yes, sorry, perhaps too much wine

What I was getting at is that C is a good language for implementing low level systems and that type of coding occasionally needs casts - but in well written code the need for type casts should generally be fairly small. If reviewing code I worry if I find casts scattered throughout the code. Something like a single cast of a void * into a correct type at the top of a function is reasonably clear and a well recognised idiom in C.

[dmills]

Oh you need test coverage tools right enough, but the correct answer to a problem like this is to shout at the test coverage tool vendor until they fix the tool, not set a horribly fragile flag in a makefile that breaks the language.

One observation from an (Ex) automotive guy, testing that "If X any not Y then Z within 100ms" is easy, testing that Z **ONLY** occurs within 100ms of those conditions is almost impossible in a non trivial system, and often the second is of FAR greater importance.
Also, CAN and friends are asynchronous and you can get races between the updates from various systems, very hard to test for.

You cannot test quality into a product, and I am having a horrible feeling that this is being attempted.

There is **PLENTY** of WTF in this thread, and the whole thing is making me far more nervous then I ever was about flying.

Regards, Dan.

[grumpydoc]

IMHO the initial decision to use a compiler modified from the language standard (by 'SET ev_shortcircuit 0') was defective.

I have to say I am in 100% agreement with this - in fact I'm quite surprised to find that the compiler even allows such a switch as it renders the environment incompatible with any C standard so that move in itself would be against MISRA  guidelines.

I'd also argue that whoever insisted on "all 4" cases for coverage does not understand C enough to be making that specification.

[legacy]

by setting coding standards forbidding boolean logical operations, thus enforcing explicit nested 'if()....else....' logic.

it's what I am manually doing to satisfy both SierraC and VectorCast: my best with ~3K lines of source code (draft version) to be modified, retested, and then validated by VectorCast, also keeping both my eyes on test reports in order to be sure that everything is correct.

I do not know WHY? they do not fix/modify VectorCast, I do not know if there are other hidden reasons in that decision

[Ian.M]

If they've done one such non-ANSI C abomination, they'll have done others.  Have an exit strategy in place in case you need to whistle-blow.

[tggzzz]

Also, CAN and friends are asynchronous and you can get races between the updates from various systems, very hard to test for.

You cannot test quality into a product, and I am having a horrible feeling that this is being attempted.

Very true. From your use of "You cannot test quality into a product", I guess you have been around for a while.

Nowadays software of all sorts is written by the very inexperienced, who believe that if all the unit tests have been passed then the software is correct. Seriously, I have heard that several times from people that ought to know better.

Given that level of ineptitude, it is unsurprising that, if they have even heard of the "byzantine generals" problem, they don't think it applies in the software they are creating.

[legacy]

who believe that if all the unit tests have been passed then the software is correct

unit tests is "minimum condition but not sufficient" ~ if ( A && ….
there are also integration tests, and a lot of other fine tests
(I am not directly involved in them, it's other dudes task)

[legacy]

"byzantine generals" problem"

nice quote 

[Jeroen3]

are you speaking about Keil/uVision using the ARMCC compiler v 5.03.0.76 ?
is GCC v>=v4.9/5.* bugged too ?

I never used gcc for arm, so I wouldn't know.
Also note that I didn't find a public list of known bugs or errata for the compiler. They probably have a list in a secure part of their website to which I do not have access.

Meanwhile this topic is turning into "engineering ethics". Should we change the title?

[legacy]

so, it's seem that I am going to understand the a few points

I have already modified a C-Grammar tool that I have written a few months ago (in order to do "inter modules dependencies"), just to automate the process of changing the if-statement (1) into (2)

(1): if (A && B) ----- automatically transformed into ------> (2): if (A) { if (B) {} }

* * * my boss * * * has said that he assigned a level-B (sub)task to me not because I am qualified as level-B-developer/tester (as I am still  level-E), but because "I am good" at creating tools in order to solve a problem.

as far as I understood, I am working on a piece of code that was originally created for a level-D in where VectorCast just needs to check if the if-statement was taken or not, it didn't matter about the True-table, and they want to "improve" it into level-B, modifying as it's needed

Code: [Select]

var.A var.B  then-branch
------------------------
False False  not taken
False  True  not taken
True  False  not taken
True   True  taken
True table, coverage, Level D..E

Code: [Select]

var.A var.B  then-branch  detailed conditions
-------------------------------------------------------
False False  not taken    with var.A=False, var.B=False
False  True  not taken    with var.A=False, Var.B=True
True  False  not taken    with var.A=True , Var.B=False
True   True  taken        with var.A=True , Var.B=True
True table, coverage, Level A..B

coverage, Level C=?!?!?!?

i am working on a draft version, which means it has passed the "normal" condition on real hardware and it's ready to be tested with "abnormal" condition, which also implies hard stress tests

as far as I understood they want to reuse (of course improving them as need) their ATP (test plan) to the ICE test, this requires "hard points" in the source code around the if-branches to allow the ICE (in circuit emulator) to collect the environment while the software is running in run-mode.

VectorCast tends to make the code "instrumented", this means modified to collect "triplets" (sampled detailed conditions) about the if-then-else statement, and also it requires debug mode, so the clock is scaled 1:x, and sometime too much intrusive

They got requested to provide a VectorCast test report (ATP), it's a MUST DONE (required by QA dudes), but they also want to provide an ICE ATP (not intrusive, but not directly requested, so it's a sort of intenral ATP): both of them requires the source code modified as my new tools is going to do (my boss justified that it costs the less, by several number of magnitude in term of dollars, than asking VectorCast-dudes to create such a tool, even if … you can't absolutely use an internal tool to do certifications, it's just for your personal engineering purpose)

Technically speaking the ICE ATP is performed with a WindRiver ICE for PowerPC440/460, it's phisically a "black box" (like a jtag-black-box but with an RJ45 plug) with a sort of hardware debug port (it's not jtag, it's not BDM, it's not NEXUS, I do not know what it is, I have no manual here, and no time to investigate, I am waiting for the first occasion to ask to an "hw" dude as soon as he will have his coffee break), with a Gigabit/sec ethernet port and up to 256Mbyte of DDR ram, able to collect thousand and thousand of triplets without breaking the CPU on hardware and software "breakpoints".

Other testes require the use of a Digital Oscilloscope (DSO), plus a test-case software (special ATP+ATR, hw dependent)

my apologies to who is heart sensitive, it's not easy to hear for me too

edit: I forgot

Last but not least, it seems that level B has the ARINC (419/429/575/573/717) interface cards with 32-bit FPGA Protocol Engine, fully configurable Bit Rate, Bit Encoding, Word Length, Start/Sync and Stop Bits. This part is covered by an other squad, a part of them has also to verify the MIL-STD-1553 compliance

So about the quality, there are a lot of people involved into the product life cycle, I do not have the full view of the process: do not take my words as THE measure of the quality in Avionics

[legacy]

Meanwhile this topic is turning into "engineering ethics". Should we change the title?

done 

[tggzzz]

who believe that if all the unit tests have been passed then the software is correct

there are also integration tests, and a lot of other fine tests

There is zero philosophical difference between unit tests and integration tests. The only trivial difference is that the units being tested have changed.

To put it another way, all the tests you think of as unit tests are actually integration tests. For example, you are integrating your code with (unit1) library code and (unit2) compiler switches, and you are integrating that with the board (unit3) containing the computer. And the board containing the computer is the integration of a processor (unit4) some memory (unit5) the i/o hardware (unit6) and all the passive components including the PCB itself (unit7).

It is integration tests all the way down to transistors[1] and wires, and all the way up to an aircraft and the ATC systems.

[1] I'll ignore the electrons, but even they become problematic with smallest geometry devices.

[dmills]

Am I the only one being slightly worried by the slavish pursuit of MISRA this and DO-17... That?

Stepping back a little, none of those things give you reliable mission critical software, at most the help with reducing the incidence of silly mistakes (So they are valuable in that respect), but compliance is neither necessary nor sufficient to end up with reliable software (And C is **really** the wrong tool for critical systems, you should be writing in something much higher level if at all practical).
I have issues with the altogether too common management assumption that compliance with these standards makes a reliable system.

For me the really dangerous bugs are usually way up at the system level, races that only trigger on average once in a blue moon, Byzantine generals, weird cascade failures because some units fail safe state transition confused some other box, all that sort of thing, they are architectural and design bugs not ones easily amenable to software verification, and almost nobody makes a proper study of formal systems theory these days.
 
And, no I have only been doing this about 25 years (And I am first and foremost an analogue hardware designer anyway), my beard is not yet grey.

Regards, Dan.

[legacy]

DO-17... That?

SW: DO178B & DO178A, level A..D+E

And C is **really** the wrong tool for critical systems, you should be writing in something much higher level if at all practical

low level: assembly, manual check and justification
wrappers: inline assembly + C (defined as "unsafe code"), they MUST be manually checked and justified
BSP: C, MISRA QAC
iBSP: C, MISRA QAC
drivers: C, MISRA QAC
RT/OS: C, MISRA QAC (usually provided by Green Hills or other Vendors, so it's already certified)
-------------------------------------- end of my task view -------------------------------------
customer App: ADA

architectural and design bugs not ones easily amenable to software verification

Avionics is strongly pipelined job (like a "chain")
someone does design -> someone checks it -> someone prepares the C,ADA -> someone prepare ATP -> someone does tests -> someone takes decisions if/what/when/who reiterate


I have seen people using "Stood", it's a "design" program with AADL (which is a MUST in DO178A/B)

[legacy]

In short, there is Model-Based Engineering with AADL (and HOOD)
their output is

• my input about C testing (ATP/ATR)
• the input to an other squad that has to verify others critical details (e.g. latency analysis)

[legacy]

AADL tools, commercial and OpenSource
book Model-Based Engineering with AADL

[Bassman59]

(Or someone did a "smart trick" of calling a function in a if statement, and that function need to be called even is the first test fail, like a :

Code: [Select]

if ( (empty == 0) && (NeedToRunFunction() == 1) )
If empty is equal to 0, NeedToRunFunction is not warranted to be run at all.

I'm mostly an FPGA guy, and I do VHDL, so I am used to (and prefer) a strongly-typed language. But I do plenty of micro firmware in C, and at two past jobs I've done Verilog. And all of this language-hopping has taught me a valuable less: don't count on language "features" like expression short-circuiting or sign-extension (Verilog is weird for this), and instead, just write explicit code.

For the example given, NeedToRunFunction() must have (because of its name) some side-effect (a hardware register access, whatever) that system operation requires. So I'd write this as:

Code: [Select]

if (1 == NeedToRunFunction())
{
    if (0 == empty)
    {
    }
}
The above makes my intentions explicit to both the compiler and the casual reader, the latter being someone who might not be as well-versed in the language as the experienced pro. (It also might be me, a year later.) I know that there's this subculture of programmers who love to do the obscure C coding thing (already referenced in this thread), but being clever doesn't score points in some game.

[amyk]

It's not "weird" or anything, it's called knowing the language. Short-circuit evaluation of || and && are literally one of the first things any C programmer should know - it's covered in section 1.5.4 of K&R. If someone can't figure out something as simple as this, I don't want to know what else they'll screw up...

[djacobow]

It's not "weird" or anything, it's called knowing the language. Short-circuit evaluation of || and && are literally one of the first things any C programmer should know - it's covered in section 1.5.4 of K&R. If someone can't figure out something as simple as this, I don't want to know what else they'll screw up...

Moreover, C is actually, a teensy, tiny language. It is not outrageous to expect a reader of C code to know the whole thing. Short circuiting expressions is part of the language. Writing truth tests without == 0 or != 0 is very idiomatic C.

Other languages are much bigger and I have more sympathy for those that suggest that code be reigned in from using every single feature. C++ is big. Perl is big. C, not so much.

[grumpydoc]

C++ is big

I confess that I had had an on-off love affair with C++ when I wrote code for a living.

On the plus side it can be a beautifully expressive language.

On the minus side any language where you have to know the exact dynamic run-time type of "a" and "b" to know whether the statement a + b; will do something akin to addition or will withdraw all of the control rods from the nuclear reactor is not one that I would feel comfortable with for the implementation of safety critical systems.

[tggzzz]

C++ is big

I confess that I had had an on-off love affair with C++ when I wrote code for a living.

On the plus side it can be a beautifully expressive language.

On the minus side any language where you have to know the exact dynamic run-time type of "a" and "b" to know whether the statement a + b; will do something akin to addition or will withdraw all of the control rods from the nuclear reactor is not one that I would feel comfortable with for the implementation of safety critical systems.

Just so.

Always worth remembering that the designers unwittingly created a Turing-complete sub-language. They were surprised when someone demonstrated that, during the compilation process you could get the compiler to emit the sequence of prime numbers, albeit very slowly. The culprit was the complexity of the interactions between templates and the rest of the language.

And that was when I vowed never to use C++ for anything non-trivial.

If the language designers didn't understand their creation, what chance is there for the rest of us?

Don't believe me? FFI: https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

[richardman]

If the language designers didn't understand their creation, what chance is there for the rest of us?

Don't believe me? FFI: https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

Template meta programming is a powerful thing in the right hands...
and very very scary in the wrong hands.

[grumpydoc]

Always worth remembering that the designers unwittingly created a Turing-complete sub-language. They were surprised when someone demonstrated that, during the compilation process you could get the compiler to emit the sequence of prime numbers, albeit very slowly. The culprit was the complexity of the interactions between templates and the rest of the language.

And that was when I vowed never to use C++ for anything non-trivial.

If the language designers didn't understand their creation, what chance is there for the rest of us?

Don't believe me? FFI: https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

I'm out of date with modern C++ but wow, WTF. That should have been shot at birth but I have a horrible feeling that the next C++ standard will add features