Re: [boost] Use of boost in safety critical work

Subject: Re: [boost] Use of boost in safety critical work
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-12-07 19:08:30

Quite a few people have already replied on this un-orthodox topic, so I 
am not sure if my reply will add any value (likely not). Still, I've 
been in rail and airline-related industries too long to remember and 
ultimately I second what Robert says below. Safety-critical is different 
from, say, embedded and it's mostly about the process and verification, 
etc. So, SOUP or no-SOUP any code will have to go through some 
verification/approval process... which is not always fun. That said, 
once an external library has come through that hurdle of initial 
acceptance -- non-SOUP certification so to speak, it does get better 
somewhat. Ultimately from my experience it boils down to your 
convictions in the value of particular s/w and your standing within the 
project. BTW, Boost's been absolutely essential in my work and IMO no 
serious project can survive without it.

On 12/06/2014 04:12 AM, Robert Ramey wrote:
> Andrew Marlow-2 wrote
>> They introduced me to a new acronym, well new to me anyway: SOUP.
>> It stands for Software of Unknown Pedigree. They classify boost as SOUP.
>>
>> I have used boost before in embedded work but I have never done safety
>> critical work before so I don't know how widely boost is used there. Can
>> anyone who *has* worked on safety critical stuff comment please?
> In my limited exposure to the "safety critical" world, a big part of
> the job is verifying/demonstrating/documenting that each safety
> requirement is fulfilled by some specific piece of code.
>
> Since Boost is distributed as source code, the issues related to verifying
> and documenting the fulfillment of safety requirements would be EXACTLY
> the same for code writing in house. So SOUP wouldn't apply
> unless all in house written code is also considered SOUP.
>
> That's the way the system is supposed to work.  I very seriously doubt
> that it actually works that way.  I'm sure all the paperwork "proving"
> that all safety requirements can be traced to specific code is filed, but
> I doubt that the work is really rigorously done.  For example, I've
> never seen any of these companies apply these verification/certification
> policies to C library source code. Actually the often will use the
> C libraries pre-built from the vendor so they haven't actually verified
> that this code even matches the library source!
>
> In many places this is used to justify a
> policy of "we make everything from scratch so we can verify it".
> This is similar to other policies such as "we make everything from
> scratch so no one can sue us".  Or "we make everything from
> scratch because we have hard real-time requirements". Or
> whatever.
>
> So it boils down with, is one
> going to start with something like Boost code or code from scratch"
>
> Since some/many Boost libraries aren't really readable they wouldn't
> likely be suitable candidates for inclusion in such a project - while
> other ones would.  In general, Boost code will be more likely to
> be correct than home brew code.  If necessary, the
> verification/certification
> would be applied to the Boost code.  That would satisfy all the
> safety certification requirements.  As far as I know, no user had
> every contacted any author of any boost library to participate
> in such a certification.  Actually, I don't think anyone who uses
> Boost (or the standard library for that matter) actually even runs
> the test suite which is delivered with the library.
>
> Robert Ramey
>
>
>
>
>
>
> --
> View this message in context: http://boost.2283326.n4.nabble.com/Use-of-boost-in-safety-critical-work-tp4669801p4669815.html
> Sent from the Boost - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost