[SystemSafety] Candidates for the firing squad

[Chris Hills]

I recalled that we discussed some of this in the MISRA-C WG re setting compiler warnings to max and removing all errors and/or warnings. (that was a fun discussion) 

 

My view was that  if the tool translating the source to binary has a problem,  i.e. a warning or error, it meant, no matter what the C standard, or a static analyser, said was correct for the source, the binary the compiler produced was suspect.   That needs to be resolved.

 

However the reverse, no warnings or errors at compile, did not mean the code was correct.  It just meant the compiler could translate it. 

Hence the requirement for static and dynamic testing.

Also a coding standard to reduce the main areas where errors and misunderstandings frequently occur. 

I have yet to find any one person who really understands all the subtleties of the whole C language. 

 

This comes back to the infamous, and much misunderstood:  MISRA RULE 1  all code will comply to the relevant ISO C standard (with all it’s unspecified, undefined and implementation defined aspects).  The point of the rule is to make the programmers document where and how the compiler deviates from the standard as a deviation.  

 

Thus you will have clarified the implementation defined and hopefully most of the unspecified and undefined items.  Also the extensions. Most C compilers used in the embedded sector are more C-like than Pure C.

 

Of course in a perfect wold  we would be using Modula 3 or Oberon. 

 

 

 

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Andrew Banks
Sent: Thursday, September 20, 2018 4:53 PM
To: 'Olwen Morgan'; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Candidates for the firing squad

 

As a corollary to this question, why do so many programmers (I hesitate to call them software engineers) disable compiler warnings?

 

That a compiler is telling you something should be a big hint!

 

If it’s generating so much noise that you have to switch off the warnings, you have a real problem!

 

A

 

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Olwen Morgan
Sent: 20 September 2018 13:55
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: [SystemSafety] Candidates for the firing squad

 

 

In the early 1990s, I was working on a project that was dedicated to improving software engineering practices. One of my jobs was to help with roll-out of static checking tools for C and C++. After setting a team up with a tool, I would check back in a week or 10 days to see how they were getting on with it.

One group for which I had installed QAC++ said that the tool didn't seem to be telling them much. It turned out that they were well disciplined coders who wrote little for the tool to flag up for them.

Another group said that they had stopped using QAC after one week because, "It complained too much about what they wrote." (Shortly thereafter, a substantial weight of bricks was dropped on them from a great height.)


Now the questions: Why do software engineers object to tools that show them errors in their code? What kind of mindset grips them?

it's yet another bizarre phenomenon that makes me think that improving software engineering needs a hefty input from cognitive psychology - in fact I'd almost go so far as to say that dilapidations of this kind might be best dealt with by cognitive behavioural therapy.


... and just a make-weight:

Back in the 1970s I was programming in COBOL for a London local authority. It was all batch-mode applications on an ICL System 4/50. Usually I got the data vets to do because I was at the time the only programmer on the site who knew anything about syntax analysis. Once one of my data vets crashed on its first operational run. A certain action needed to be performed twice at a certain point in the program. I had made a note of it but simply forgot and put the action in only once.  After the program had crashed, I found the fault and corrected it in about half an hour, whereafter the program ran without further problems.

Later that day I went down to the ops staff to apologise for the error that had caused the crash. By afternoon I found that I had become a laughing stock among the programmers, not for making the error but for apologising for it.

... WTF? ....


Now that my lithium is kicking in (seriously, I do have to take it), the manic postings will subside.



O



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180920/89c377b3/attachment.html>