-
Notifications
You must be signed in to change notification settings - Fork 37.7k
net: make the list of known message types a compile time constant #29421
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net: make the list of known message types a compile time constant #29421
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Concept ACK 2e312ea. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2e312ea
to
808fe4e
Compare
|
808fe4e
to
c29350f
Compare
c29350f
to
c7c613c
Compare
Concept ACK |
Seems fine, but NACK on the approach. This switches a vector of |
c7c613c
to
fd6a481
Compare
|
fd6a481
to
546d132
Compare
@maflcko good point! Changed from |
Turn the `std::vector` to `std::array` because it is cheaper and allows us to have the number of the messages as a compile time constant: `ALL_NET_MESSAGE_TYPES.size()` which can be used in future code to build other `std::array`s with that size.
As a side effect the names of the constants do not have to be repeated in `src/protocol.cpp`.
546d132
to
b3efb48
Compare
|
@maflcko, this has a NACK from you and I have addressed your concern. If not ACK, it would be nice if you can at least remove your NACK. Thanks for the review so far! |
ping @maflcko |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK b3efb48
@@ -7,87 +7,6 @@ | |||
|
|||
#include <common/system.h> | |||
|
|||
#include <atomic> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated change, but looks fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for missing the ping. Now it looks good, because the only change is vector->array and some style fixups.
utACK b3efb48 🎊
Show signature
Signature:
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: utACK b3efb486732f3caf8b8a8e9d744e6d20ae4255ef 🎊
SkLePLuDXM+ymjKH3KbyoYmBU/CTns4Bd4K8JycRF2zRDl2t3QMwQrGtZcNnOZ88NGBjgAWuIpsGTMsQzwHKBw==
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK b3efb48
Based on range diff from previous ACK, all looks good!
range-diff 2e312ea...b3efb48
ACK b3efb48 |
/** | ||
* The version message provides information about the transmitting node to the | ||
* receiving node at the beginning of a connection. | ||
*/ | ||
extern const char* VERSION; | ||
inline constexpr const char* VERSION{"version"}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well make these std::string
? Or is there still a good reason that these are char*
? (it used to be that the message-making functions took char*, but i don't think that's the case anymore)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC this was left because constexpr std::string
was not available, but perhaps it is now in c++20?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i mean it's defining an array of std::string
constexpr below it, so i would expect single std::strings to be possible too, i haven't tried it though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it could make sense to switch this from brittle raw pointers literals to type-safe string_view
or string
in a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, IIRC string_view
was tried in this pull and needed more patches, so it was left for a follow-up what to do here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was tried: #29421 (comment)
Here is a draft that changes to std::string_view
the following:
NetMsgType::*
ALL_NET_MESSAGE_TYPES
CMessageHeader:pchCommand
(renamed toCMessageHeader:m_command
)CNetMessage::m_type
V2_MESSAGE_IDS
V2MessageMap::m_map
V2Transport::m_send_type
and the functions that handle message types.
The scope of this can be reduced by converting the std::string_view
to std::string
at some point. The previous code uses std::string
(or char*
) everywhere.
https://github.com/vasild/bitcoin/commits/NetMsgType_string_view/
Turn the
std::vector
tostd::array
because it is cheaper and allows us to have the number of the messages as a compile time constant:ALL_NET_MESSAGE_TYPES.size()
which can be used in future code to build otherstd::array
s with that size.This change is part of #29418 but it makes sense on its own and would be good to have it, regardless of the fate of #29418. Also, if this is merged, that would reduce the size of #29418, thus the current standalone PR.