On 14 August 2017 at 10:27, Peter Smith peter.smith@linaro.org wrote:
Perhaps the most difficult decision is whether to support exceptions. For your own code, choosing not to support exceptions isn't a problem as both gcc and clang can compile without exception tables, however many C++ libraries, including the standard library make use of exceptions, and an uncaught exception results in program termination. The libc++ library can be compiled without exceptions but this just means it will terminate the program if an exception would be thrown.
Most standard library exceptions can be easily worked around with a bit of kludge, for example out_of_range, bad_cast, overflow_error. Others may require a more complicated setup, like special allocators that don't throw bad_alloc. A few can be simply never used (ex. bad_exception and bad_typeid).
However, from what I gather about OP-TEE, you guys need a secure environment, and relying on the whole C++ standard library (especially a third-party one, even open source) is not feasible.
Honestly, I don't think you should even have threads support, or exceptions, or type-ids or rely on the default allocators, nor you should rely on C/C++ compilers to tell you anything about safe ranges and casts. All those things are riddled with security issues and shouldn't be trifled with.
In the past, I have used C++ with only the C library (for performance purposes) and if you restrict the functionality to a minimum, it should be much easier to control the side effects.
The LLVM project is one example where we control some parts of it and keep most. The European Space Agency has a long document [1] on their own restrictions of the language, showing a different type of restrictions, which may line up closer to your needs.
cheers, --renato
[1] http://www.esa.int/TEC/Software_engineering_and_standardisation/TECRFBUXBQE_...