-
Notifications
You must be signed in to change notification settings - Fork 37.7k
refactor: Use spans of std::byte in serialize #23438
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
Conversation
Oh, |
There seems to be a bug on msvc, because it doesn't eat the code I prepared. There is also no error. Any ideas @sipsorcery ? |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. 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. |
Seems to be a const change for a Changing this line to the below fixes it (I added the const cast):
But perhaps a better thing to do would be to remove the build_msvc/testconsensus directory completely. It's a test app that, in hindsight, would have been better put into a unit test somewhere. I suspect no one ever uses it. I haven't looked at it in the 4 years since I first wrote it... I'll submit a PR to remove it. |
The testconsensus project is not integral to the Bitcoin Core code. It was originally added as a quick and dirty demo of how to do a consensus check with the msvc build. There are better examples. PR bitcoin#23438 made a change that caused a compiler error with the buildmsvc/testconsensus code. Rather than leave it hanging around to incur potential bitrot, or furhter PR build failures, it should be removed.
bb1c840 Remove the build_msvc/testconsensus project (Aaron Clauson) Pull request description: The testconsensus project is not integral to the Bitcoin Core code. It was originally added as a quick and dirty demo of how to do a consensus check with the msvc build. There are better examples. PR #23438 made a change that caused a compiler error with the buildmsvc/testconsensus code. Rather than leave it hanging around to incur potential bitrot, or further PR build failures, it should be removed. ACKs for top commit: hebasto: ACK bb1c840, tested on Windows 10 Pro (20H2). Tree-SHA512: d81b99eb09171b66c179961b15f0b2e2e97e5ee7f011f18667e890c90e3d169593ad9aedd05a8616e962212952048827b7159d3c2a2ecb7ac378136b80bf6b23
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.
utACK face063
Thanks, force pushed to replace data-end with begin-end. |
re-utACK fade794 |
This switches .read() and .write() to take spans of bytes.
Rebased due to silent conflict. Trivial to re-review via |
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.
utACK
I have reviewed the code, and didn't find any issues.
I am very happen to see std::byte being used, as well as spans :) All good refactoring as far as I can tell
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.
re-utACK fa5d2e6
IMO, this PR could be merged. It's been 17 days w/o any review, and two acks. And it's been in high-priority for review for 7 days. I'm not sure what exactly the procedure is for bitcoin-core, but I think this relatively simple refactoring PR can be merged at this point. |
There is no strict procedure in this project, but if a pull request hasn't been merged, it can either mean that all maintainers that looked at it preferred more review, or it can mean that it went unnoticed from maintainers. |
Concept and code review ACK fa5d2e6 |
@@ -421,7 +422,7 @@ class CDataStream | |||
} | |||
|
|||
for (size_type i = 0, j = 0; i != size(); i++) { | |||
vch[i] ^= key[j++]; | |||
vch[i] ^= std::byte{key[j++]}; |
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 think it would make sense to make ObfuscateKey a std::byte
throughout, avoiding this cast. Though no need to do so in this PR. Could also pass in a span here then instead of const std::vector<unsigned char>&
.
…alize" This reverts commit cc616fe.
This changes the serialize code (
.read()
and.write()
functions) to take aSpan
instead of a pointer and size. This is a breaking change for the serialize interface, so at no additional cost we can also switch tostd::byte
(instead of usingchar
).The benefits of using
Span
:Span
(-like) object to or from serializationThe benefits of using
std::byte
:std::byte
can't accidentally be mistaken for an integerThe goal here is to only change serialize to use spans of
std::byte
. If needed,AsBytes
,MakeUCharSpan
, ... can be used (temporarily) to pass spans of the right type.Other changes that are included here: