[SystemSafety] Candidates for the firing squad

[SPRIGGS, John J]

Many decades ago, I had a project from a Customer who specified exactly what C compiler we had to use.  The software guy used a different one for program development, because it generated more warnings than the mandated one, which we just used at the final testing to "ready for integration".  So, not everybody turns off diagnostics...


John

-----Original Message-----
From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of David Haworth
Sent: 21 September 2018 07:12
To: Chris Hills
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Candidates for the firing squad

On 2018-09-20 17:31:17 +0100, Chris Hills wrote:
> 
>    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.

The only minor problem with that is that, if you are developing software that has to be compiled with a wide range of compilers and processor architectures you're almost bound to find some warnings that you can't get rid of unless you build compiler detection into the code.

Typical example: a range check on an enumerated type. Because the signedness is implementation-defined, if you test for < 0 you'll get a warning (expression is always true) sometimes.
But you can't leave it out ...

We use a static analyser that comes with a MISRA-C checker.
The part that does the MISRA-C rules assumes one of the choices and the part that does the call tree and path analysis assumes the other ... :-)

And don't start me on "possible endless loop" for "while (1) {}" - although I have to say that some compilers that warn about this don't seem to care about "for (;;) {}"

Dave

-- 
David Haworth   OS Kernel Developer              david.haworth at elektrobit.com
Elektrobit Automotive GmbH                            Tel: +49 9131 7701-6154
Am Wolfsmantel 46, 91058 Erlangen, Germany            Fax: +49 9131 7701-6333
Geschäftsführer: Alexander Kocher, Gregor Zink     Amtsgericht Fürth HRB 4886
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

***************************************************************************
If you are not the intended recipient, please notify our Help Desk at Email information.solutions at nats.co.uk
immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose
their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to 
secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses
caused as a result of viruses and it is your responsibility to scan or otherwise check this email
and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd 
(company number 4129270), NATSNAV Ltd (company number: 4164590) 
or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). 
All companies are registered in England and their registered office is at 4000 Parkway, 
Whiteley, Fareham, Hampshire, PO15 7FL.

***************************************************************************