Botan 3.0.0-alpha0 with C++14

[pist-eb]

Recently we started integration of Botan 3.0.0-alpha0 in our commercial automotive project. The first steps look promising, but we encountered a problem with libstdc++ and compiler version in the target environment. It is limited to C++14 and cannot be upgraded. After quick checking, it is possible to patch the Botan's code to use experimental features and replace C++17 language features with corresponding C++11/14 counterparts, however this will not be convenient. On the other hand, we need to stick to 3.x.x version in order to implement TLS 1.3 protocol.

One of the ideas to resolve the problem would be to define a 'c++14 compatibility mode', where the -std=c++14 will be used by default, while the C++17 features will be replaced: experimental? boost? c++11/14 constructions? We raise this topic here, as it might also be valid for other users of Botan, especially in automotive domain, where the compilers and c/c++ versions are not switched and upgraded often.

Another limitation would be the AUTOSAR specification, which selected C++14 as a programming language for Adaptive platform and applications and this could be another blocker for using the Botan 3.x.x in automotive use-cases.

[randombit]

Unfortunate. I do understand (especially given the libraries apparent widespread usage in automotive/embedded/industrial contexts) that toolchains often are somewhat old and difficult to upgrade and in general this is something I'd like to accommodate. I had hoped that (in 2021) picking C++17 was sufficiently behind the curve that this would be safe enough (vs jumping to C++20). I guess I'm glad this issue was caught early before too many C++17 specific features had been adopted.

FWIW it looks like with the AUTOSAR/MISRA merger they are updating to C++17, not that this changes the current situation.

Is your toolchain GCC based? If so what version? That would be useful for setting a baseline for testing. Is it possible for you to use Boost (and/or Fundamentals TS 1) in your environment? I'm specifically looking at std::optional which is already used heavily, we'd need some alternative there.

IMO the best approach here is to maintain 3.0 proper as being C++17 and additionally offering a branch which builds as C++14 plus whatever additional libraries prove necessary. The C++14 branch can rebase from the C++17 branch as needed. It's CI would run the full test suites but everything would build as C++14. In particular this makes it possible to continue evolution on master incl adopting further C++17 features where it makes sense; if we can't easily backport something then those changes would just be dropped from the C++14 branch. So this branch would track the 3.x releases, but might not contain all of the same features - and there would not be official release tarballs, just tags in git. Basically I would want to do everything possible to encourage users not to use this branch unless they truly must, for reasons such as your own.

At whatever point it is possible to upgrade your toolchains (I understand that's not likely to happen in the context of your current projects, but for future developments), the C++14 branch can simply be deprecated/ignored. Whereas if we are maintaining C++17 vs C++14 within master, then it is another big project to remove all of build-time hacks and macro checks etc that were added in the first place.

WDYT?

[pist-eb]

Thank you for quick response!

Is your toolchain GCC based? If so what version? That would be useful for setting a baseline for testing. Is it possible for you to use Boost (and/or Fundamentals TS 1) in your environment? I'm specifically looking at std::optional which is already used heavily, we'd need some alternative there.

The toolchain is based on GCC 7.3.0 and we can either use boost or Library Fundamentals V1 TS (already checked both approaches to compile Botan 3.0.0-alpha0 with C++14 and there shall not be a problem, at least now, when there is not much C++17 yet). https://gcc.gnu.org/onlinedocs/gcc-7.3.0/libstdc++/manual/manual/status.html#status.iso.2017

Using experimental GCC features would benefit in lack of external dependency to Boost (preferable in our case). On the other hand it introduces the limitation for minimal version of GCC that can be used, but such a limitation will also be valid for minimal boost version anyway. Please, take the approach that you think is better for you/Botan Community and we'll align.

IMO the best approach here is to maintain 3.0 proper as being C++17 and additionally offering a branch which builds as C++14 plus whatever additional libraries prove necessary. The C++14 branch can rebase from the C++17 branch as needed. It's CI would run the full test suites but everything would build as C++14. In particular this makes it possible to continue evolution on master incl adopting further C++17 features where it makes sense; if we can't easily backport something then those changes would just be dropped from the C++14 branch. So this branch would track the 3.x releases, but might not contain all of the same features - and there would not be official release tarballs, just tags in git. Basically I would want to do everything possible to encourage users not to use this branch unless they truly must, for reasons such as your own.

This sounds like a good plan. I suppose that tag-based 'releases' shall be fine. If the C++14 branch follows the C++17 master with the most important features and bug fixes, then it might save the day for many current and future users :) Do you have any idea, when such a C++14 branch could be created and tagged for preview purposes?

At whatever point it is possible to upgrade your toolchains (I understand that's not likely to happen in the context of your current projects, but for future developments), the C++14 branch can simply be deprecated/ignored. Whereas if we are maintaining C++17 vs C++14 within master, then it is another big project to remove all of build-time hacks and macro checks etc that were added in the first place.

I agree, this sounds like quite painful work.

[pist-eb]

@randombit: Would it be possible to create such a c++14 based branch and draft a tag for preview version?

[randombit]

@pist-eb Pushed as master-cpp14 or just apply 769e036 onto the existing alpha0

[randombit]

master has moved to C++20 and makes supporting C++14 simultaneously almost impossible. Due to limitations of manpower, the attempt to provide a C++14 version is abandoned.