[I guess ->SG12]

On Wed, Jul 24, 2013 at 3:25 PM, Ion Gaztaņaga <igaztanaga_at_[hidden]> wrote:
> El 24/07/2013 20:28, Jeffrey Yasskin wrote:
>>
>> IMO, C doesn't need to change for this. The memcpy approach works fine
>> there in the current language, and C99 already includes vague
>> permission to use unions to type-pun. In cases where C++ supports a
>> library solution to some problem, we shouldn't insist on a language
>> solution just because C is designed for portability instead of
>> programmability.
>
>
> I tend to disagree. In some areas we can't use the standard library so a
> library solution wouldn't be enough. If you need to design a safety-critical
> system (say, in railway, avionics or nuclear industries), all your code must
> conform to an strict set of limitations and all your code must have been
> certified to be safe.
>
> You can't even "#include" a single header if that header is not guaranteed
> to be certified. C++ use for these systems is growing (strictly speaking, a
> non-specified "subset" of the language that is described in your coding
> standard, usually following some "well-known" coding standards, like MISRA
> C++ or JSF++).


> Certified C++ compilers for safety-critical systems are
> already available in order to guarantee that the source you write equivalent
> to the machine code that will be generated (otherwise, you'd need to test
> the executable code generated by the compiler very thoroughly).

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.)

...

> In safety code, we can't #include<cstring> and call memcpy, as memcpy is a
> function that comes in a non-certified library. We could try to extract the
> assembler code of this library function and try to certify it or try to
> write our own memcpy version in assembler. ... We wrote
> our memcpy function relaying on UB (type punning, in order to write properly
> aligned memory using 4 byte accesses) and testing the implementation with
> our compiler at high optimization levels.

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?

Note that tests for undefined behavior are really hard to write. It
generally depends on details of optimization passes, which
non-compiler-authors usually don't understand. I've seen plenty of
tests in this area that turn out to have no chance of provoking the
problematic behavior, even though non-test uses actually break.


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.

Jeffrey