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:
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
Andrew Marlow-2 wrote 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-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost