Upgrade the minimum compiler C++17 #116
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Grr, this triggers new clang-tidy checks |
These calls are deprecated, and moving them out to the implementation means they are only pulled when BUILD_P11 is set.
See discussion on #106 Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that: * Debian oldstable shipped with gcc-10. * The oldest supported Yocto release is Dunfell, which shipped gcc 9.5 That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream. Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.
cajun-rat
force-pushed
the
chore/bump-cpp-compiler
branch
4 times, most recently
from
9af8705
to
d97369e
Compare
Upgrading the target language version also results in more clang-tidy warnings. Fix up many of these, and disable the rest. I also created #117 to discuss a more robust approach to putting clang-tidy in the build.
cajun-rat
force-pushed
the
chore/bump-cpp-compiler
branch
from
fd51ae5
to
52bbaaa
Compare
rborn-tx
approved these changes
Aug 11, 2024
| @@ -78,7 +78,7 @@ P11Engine::P11Engine(boost::filesystem::path module_path, std::string pass) | |||
| LOG_DEBUG << "Slot token model.......: " << slot->token->model; | |||
| LOG_DEBUG << "Slot token serialnr....: " << slot->token->serialnr; | |||
|
|
|||
| uri_prefix_ = std::string("pkcs11:serial=") + slot->token->serialnr + ";pin-value=" + pass + ";id=%"; | |||
| uri_prefix_ = std::string("pkcs11:serial=") + slot->token->serialnr + ";pin-value=" + pass_ + ";id=%"; | |||
There was a problem hiding this comment.
That's a bug fix on its own, isn't it?
There was a problem hiding this comment.
Yes. It was caught by the new compiler warnings :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See discussion on #106
Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that:
That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream.
Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.