Boost logo

Boost :

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:
> Sent from the Boost - Dev mailing list archive at
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at