rnpgp / rnp

RNP: high performance C++ OpenPGP library used by Mozilla Thunderbird
https://www.rnpgp.org
Other
196 stars 55 forks source link

Consider upgrading step-by-step to C++ #656

Closed ronaldtse closed 6 years ago

ronaldtse commented 6 years ago

Description

From @henrydcase

RNP needs to expose FFI interface (in C) in order to make it possible to use it as a library, but we have FFI interface already better integration with Botan (as it uses C++) no need to improve FFI interface in botan whenever some non standard feature is needed no need to call via FFI Provides some tools to make it easier to cope with memory leaks/memory corruptions etc. but doesn't solve the problem Little effort needed to convert existing code base to C++ (meaning make it possible to compile with g++) A lot of tools for code quality improvement/performance/debugging/testing/fuzzing/performing symbolic execution etc. NeoPG uses C++ - and it has some page on pros/cons of using it: https://neopg.io/blog/cplusplus/ (I havn't read it actually) BoringSSL (which is similar to RNP in a sense that it's also middleware library) is switching to C++

From @dewyatt

Would make memory management a bit easier (less time tracking down leaks, mostly). Replace labels+goto with ctor+dtor/RAII for cleaner and safer code. Slightly less bugs from rolling our own things that the STL provides, though this depends on the policy towards exceptions (Mozilla historically avoided the STL for this reason IIRC). Yes but I would suggest starting off with a set of minimal features. Like allow everything inherited from C, plus all STL containers, general templates (no TMP). Determine what standard, all those little details. We could actively try to rewrite error-prone looking functions. Or we could just use C++ when writing new functions (and kind of propagating out when useful). Switch to consuming C++ libs that make resource mgmt simpler. It would probably make sense to evaluate each dependency individually and determine what alternatives there are, what benefits, etc Having the FFI be C99 would be adequate

From @randombit

C++ is an easy "conversion" and I think by strictly limiting which language features are used many of the C++ footguns can be avoided. For example, just adding usage of vector, string, map, unique_ptr, and some simple RAII wrappers a lot of verbosity and bugs can be avoided. Adopting Botan's C++ API would also probably make some code simpler. Switch to CMake from auto*/m4 Switch dependent libraries. For example https://github.com/nlohmann/json vs json-c, {gtest,catch,boost.test,...} vs cmocka Maintain a C API via FFI

dewyatt commented 6 years ago

I think this can be closed.