[SystemSafety] C for OSs

Mon Sep 16 12:03:18 CEST 2019

There is no One Book. 

To do that starts another religion. 

What amuses me is that people will recommend the K&R  book to learn C from.  The second edition is nearly 30 years old.  Since the second edition the C standard has grown in size many times over and the book covers a fraction of the language,  some of which has changed. 

Even in 2019 I have found people using C11 and C18 who have the K&R 1st edition from the 1970’s and recommend it to new programmers to learn from as it is “The bible” of C.   

However the principals of Software Engineering are reasonably stable. 

From: Gergely Buday [mailto:gbuday at gmail.com] 
Sent: Monday, September 16, 2019 8:05 AM
To: safetyyork at phaedsys.com
Cc: The System Safety List; Olwen Morgan
Subject: Re: [SystemSafety] C for OSs

"The problem is the industry was flooded with a huge number of self-taught programmers."

What book should we base the teaching of software engineers? Where is the holy grail of true software engineering?

- Gergely

Chris Hills <safetyyork at phaedsys.com> ezt írta (időpont: 2019. szept. 15., V 19:40):

Hi,

(catching up which is what Sunday afternoons are for) 

I have often said at conferences, much to Rod’s horror, that C can be made as good as SPARK.  I then start going through some of the things you are going to have to do to subset and sort out on the way  when I usually get interrupted by someone (other than Rod) to say “wouldn’t it be easier to use SPARK in the first place?”  To which the answer is “yes”     

The problem is not technical in the way most think.  

As Derek Jones said early on in this “Another way of looking at this is as a statistical sampling problem. If the most heavily used OSs are written in X, then X will experience the most faults.” So we should be careful what, and how we are measuring these things.  

And as David MENTRÉ said:-  As usual, the problem is more social than technical: people don't want to change their habits, because they cannot due to external constraints, or think they cannot due to external constraints.

So simply changing the language used is not going to stop the problem, merely change it.  Going back to my first point about C and SPARK.  If programmers were Software Engineers and properly engineered software (which is a social problem)   things would be very different and all software would be written as though it was for a critical system.

As an aside I now say “critical software” and explain that safety, security, mission or commercially critical are all the same. Unless your brief is to write buggy and incomplete code…

You can write bad software in most languages.  Simply relying on the language implementation tools as a primary (and often only method)   to stop the developers doing something silly is not really a good idea.

I once had to work in Modula 2  “because Mod2 had an ISO standard” and was “good” this was the year before the ISO C standard. However the 3 compilers we had for Modula 2 has some major differences and some serious faults.  So whist the theoretical language was “good” the implementation was dangerous. 

What is needed is a complete change in the way software is developed at a social level.   

I blame Clive Sinclair. 

When he flooded the UK with home computers anyone who could copy type a program from “your ZX80”  magazine into their Sinclair ZX80 and get it to run was A Programmer.  If you could modify it and it still ran you were A GURU.   The problem is the industry was flooded with a huge number of self-taught programmers.  Where in the land of the blind a one eyed man is king.  Many of the bad habits and attitudes in software can be traced back to the 1980’s  and 90’s.  Many can still be seen alive and well 40+ years on. 

If we solved that problem software would be far more reliable and the differences between C programs and SPARK  programs would be an order of magnitude (or two) less.   They would still be there but you have to ask would C 90 have been allowed to run off in to  C99 and C11 without first fixing the problems in C90

Regards

   Chris 

Phaedrus Systems Ltd         

FREEphone 0808 1800 358    International +44 1827 259 546
Vat GB860621831  Co Reg #04120771
Http://www.phaedsys.com <http://www.phaedsys.com/>   chills at phaedsys.com 

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Olwen Morgan
Sent: Monday, September 9, 2019 11:14 AM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] C for OSs

For the avoidance of doubt, IMO you cannot equal SPARK Ada code quality in C. I've only ever said that you can approach it (albeit, I'm confident, fairly closely) by using different best-of-breed tools and exercising a severe coding discipline that takes a long time - and perhaps a peculiar mindset - to acquire.

And all that hassle really shouldn't be necessary in the first place.

Olwen

This email has been scanned by BullGuard antivirus protection.

For more info visit www.bullguard.com <http://www.bullguard.com/tracking.aspx?affiliate=bullguard&buyaffiliate=smtp&url=/> 

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com <http://www.bullguard.com/tracking.aspx?affiliate=bullguard&buyaffiliate=smtp&url=/> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190916/8dee4544/attachment.html>