[ub] [c++std-core-23865] Re: unions and undefined behavior

Ion Gaztañaga igaztanaga at gmail.com
Fri Jul 26 00:09:22 CEST 2013


El 25/07/2013 1:55, Jeffrey Yasskin escribió:
> [I guess ->SG12]

Yes. I'll subscribe to the mailing list ASAP.

> How does safety certification work for C++ compilers (or compilers in
> general)? Do they specify the compiler's behavior in the face of
> constructs that the standard leaves undefined? (If so, how? That could
> be useful for the UB group.)

They don't specify the behavior, that would be impossible for some UB 
cases. I don't know the details about how the compiler was certified, 
but since the compiler can directly introduce errors in the software the 
whole lifecycle of the product must be as strict as the lifecycle of the 
safety-critical software. It must be perfectly defined, reviewed and 
tested according to the highest safety level, applying safety analysis 
and mitigating the risks. The only certified compiler I know is Green 
Hills Multi:

http://www.ghs.com/products/MULTI_IDE.html#safety

it's using the EDG fron-end (this information is public in the EDG 
website, http://www.edg.com/index.php?location=customers_oc). A very 
high-level view of tool qualification is given here:

http://www.exida.com/index.php/blog/indepth/tool_qualification_and_safety_standards

http://www.embedded.com/design/prototyping-and-development/4007228/3/How-to-verify-your-compiler-for-use-in-IEC-61508-safety-critical-applications

I don't know if the safety assessor required and reviewed design and 
test documents for all compiler parts (including the EDG front-end) or a 
very deep testing requirements were added (and tested against other 
compilers to test the same outputs were achieved).

What the compiler does regarding UB is to add several compile-time 
runtime checks that should be used during development and testing phases 
(unit-testing, integration tests...). Those checks are disabled for 
production code. This can at least reduce the presence of UB. Runtime 
checks also include checks for some coding standards like MISRA C 
(trapping on legal but usually dangerous operations like unsigned 
integer overflows or the absence of enough case labels in switch 
statements). typical checks include division by zero, null pointer 
dereference, signed integer overflow, stack overflow, freeing memory 
twice, etc. The runtime checks have quite a big size and performance 
impact (executable code might be increased by 150%).

> Assuming that the certified compiler doesn't specify its behavior for
> situations the standard leaves undefined, this sounds crazy. Because
> you didn't have the resources to inspect the implementation of memcpy,
> you wrote an implementation that knowingly violates the rules under
> which your certified compiler produces expected output? And the
> independent safety assessor was happy with this?

The assessor was not happy, but we needed to inspect the assembler 
produced by the compiler where our memcpy was used in our application. 
That was a big job but convinced the assessor that this implementation, 
for our compiler and our optimization levels, was correct. That is, we 
needed to demonstrate that what the UB was for our compiler.

> Note also that with clang and gcc, you can call __builtin_memcpy to
> get defined and optimized behavior even without #including <string.h>.
> It may be replaced with a library call if the compiler doesn't
> optimize it, and your certified compiler may not provide the same
> feature.

Thanks for the explanation. A built-in memcpy is one of the language 
features that I miss, as it seems to be the only way to do bit-casts 
that are essential in some embedded domains (inspecting network packets, 
data serialization...). A conforming freestanding implementation could 
also include memcpy. That would not fix the problem for safety-critical 
Sw but would be a good low-level tool for embedded developers that don't 
want to write their own memcpy function in assembler.

Best,

Ion


More information about the ub mailing list