On 14 August 2017 at 10:27, Peter Smith <peter.sm...@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_0.html _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain