Skip to content

Conversation

theStack
Copy link
Contributor

@theStack theStack commented May 22, 2020

This PR is inspired by a recent code review comment on a PR that introduced new functions to the net_processing module. The point of the discussion was basically that whenever we pass something not by value (in the concrete example it was about CNode* and CConnman*) we should either use

  • a pointer (CType*) with null pointer check or
  • a reference (CType&)

To keep things simple, this PR for a first approach

  • only tackles CNode* pointers
  • only within the net_processing module, i.e. no changes that would need adaption in other modules
  • keeps the names of the variables as they are

I'm aware that PRs like this are kind of a PITA to review, but I think the code quality would increase if we get rid of pointers without nullptr check -- bloating up the code by adding all the missing checks would be the worse alternative, in my opinion.

Possible follow-up PRs, in case this is received well:

  • replace CNode pointers by references for net module
  • replace CConnman pointers by references for net_processing module
  • ...

@maflcko
Copy link
Member

maflcko commented May 22, 2020

Concept ACK for the reasons you mention.

Review should be easy, but this might conflict with some other work in net processing which is going on right now. Let's wait for DrahtBot to list the conflicts to get a better idea when a change like this is least disruptive.

@instagibbs
Copy link
Member

concept ACK(boo pointers) and agree this should be fairly simple to review.

@jnewbery
Copy link
Contributor

Very mild concept ACK. Pass-by-reference makes sense for CNode since we can't call ProcessMessages() with a null CNode and we never rebind the node reference when we're in net processing. Passing by reference should generally be the preferred way to pass in-out params (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-inout)

@theStack theStack force-pushed the 20200522-refactor-use-cnode-references-within-net_processing branch from a9b2cd9 to cbd6094 Compare May 22, 2020 18:16
@practicalswift
Copy link
Contributor

Strong concept ACK

@DrahtBot
Copy link
Contributor

DrahtBot commented May 22, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, 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.

@maflcko
Copy link
Member

maflcko commented May 22, 2020

Hm. Let's wait until a bunch of those conflicts are in first.

@practicalswift

This comment has been minimized.

@maflcko
Copy link
Member

maflcko commented May 23, 2020

@practicalswift This seems off-topic here. They need a case-by-case evaluation. I suggest you create a brainstorming issue to discuss this.

@practicalswift
Copy link
Contributor

practicalswift commented May 23, 2020

@MarcoFalke Yes, that these need case-by-case evaluation goes without saying: the lists are showing potential candidates only -- sorry if that was unclear :)

@theStack
Copy link
Contributor Author

Thanks to all for the quick conceptual reviews! Will rebase every once in a while to get an updated list of conflicts by Drahtbot. @practicalswift: Nice, that's for sure helpful commands for finding more replace-pointers-by-references candidates (always impressed by your mega-grep-sed-etc..-chains ;-)). I agree with MarcoFalke though that opening an issue would make sense here, also to potentially attract more people discussing/working on this.

@theStack theStack force-pushed the 20200522-refactor-use-cnode-references-within-net_processing branch 2 times, most recently from c964281 to a570157 Compare May 26, 2020 13:41
@theStack
Copy link
Contributor Author

Rebased.

@maflcko
Copy link
Member

maflcko commented May 30, 2020

has three acks already, so let's get that in before this one.

@jnewbery
Copy link
Contributor

Review comment from #19044 (#19044 (comment)): since the parameters are no longer pointers, they shouldn't be called pnode, pfrom and pto. I think the variable name peer makes sense in all cases, but there's plenty of opportunity to bikeshed that.

@maflcko
Copy link
Member

maflcko commented May 30, 2020

Doesn't p in pfrom already mean peer? 🤔

@sipa
Copy link
Member

sipa commented May 31, 2020

No, see https://github.com/bitcoin/bitcoin/blob/v0.3.17/coding.txt#L35.

@maflcko
Copy link
Member

maflcko commented May 31, 2020

Will review after rebase

@theStack theStack force-pushed the 20200522-refactor-use-cnode-references-within-net_processing branch from a570157 to 8b3136b Compare June 2, 2020 11:15
@theStack
Copy link
Contributor Author

theStack commented Jun 2, 2020

Rebased.

Review comment from #19044 (#19044 (comment)): since the parameters are no longer pointers, they shouldn't be called pnode, pfrom and pto. I think the variable name peer makes sense in all cases, but there's plenty of opportunity to bikeshed that.

Thanks, good point! Before I start renaming: are there any other opinions on the naming suggestions? I also think peer (or node) for all those cases would be fine, though one could argue that the information on the message direction is lost in the name.

@maflcko
Copy link
Member

maflcko commented Jun 2, 2020

ACK 8b3136b 🔻

Show signature and timestamp

Signature:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK 8b3136bd307123a255b9166aa42a497a44bcce70 🔻
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
pUgYLwv/c9bS0cnJ+GOBDdUcgtKm/Ppzag390mFQ/y1/buwrd+uPlTUMxrJsOcPq
NDfhbH0yE3D3+ZpXJ7F3YKuoClsFx8Hsc/kfm06C2BbJ2adpROQnpgJDQ89rvHsf
n1hdiWSltXJJP2Otgo4ebR9QUMpsgeHj3ZpQODwNhAZ6p4i4dnTde+FEBI+aM6bz
0C/05YhduIce1sKTxuGU3VJYegjhqQ4oTxe8Ej4YlExCyEBrZ1cSlfhWjbxFVdW1
7Ax6MO6LIvzMx32c/2OSUA4J+3VdX8kdY9DSI8yhCLyaj4glNmrDpJ27YBWybzP+
/29WsCtrV08yKMQrx05jY93wpd+jGW75jJKao+cilSxEtaZZpydGBtF25PdI2a1w
F6uptyxYDec/G8QOMzCTa+7+zI7OB5eJkKJJ0Q6J1UjE4fQSk0oM2+sG1nHs637Y
K1xzRP1CQhT4uybFbR1yzIFjC99C5icvARVxagZIlDFKkP6f4ErE7p+VaBONsbU/
l0f3mGjA
=2B9E
-----END PGP SIGNATURE-----

Timestamp of file with hash 1a1913878ea3e329bad84656db36b61c6f84e595e6167b335174ea5beeea883c -

@maflcko
Copy link
Member

maflcko commented Jun 2, 2020

I like that the only changes are foo-> to foo., which wouldn't compile if foo was a raw pointer. I also like that it keeps all symbol names as they were before. If they were changed, that would make review harder because generic names such as peer could be shadowed by similarly named symbols from outer or global scopes. And while p used to mean pointer, I don't see why it can be changed to mean peer instead (without having to change code at all).

So my preference would be to keep the names as they were, but no strong opinion. Though, if the names are changed, it should be done in a new commit, so that scripts can be used to help review.

@practicalswift
Copy link
Contributor

practicalswift commented Jun 2, 2020

ACK 8b3136b

Checked that set of inserted/deleted characters appear to be limited to *&>.- (as expected when changing from -> to ., and from * to &) and the string "const" (which was added for GetFetchFlags and UpdatePreferredDownload) by doing the following quick sanity check:

$ curl -s https://patch-diff.githubusercontent.com/raw/bitcoin/bitcoin/pull/19053.patch | \
      grep -E '^[+-][^+-]' | cut -b2- | tr -d "*&>.-" | sort | uniq -c | grep -E '^ *1 '
      1 static uint32_t GetFetchFlags(CNode pfrom) EXCLUSIVE_LOCKS_REQUIRED(cs_main) {
      1 static uint32_t GetFetchFlags(const CNode pfrom) EXCLUSIVE_LOCKS_REQUIRED(cs_main) {
      1 static void UpdatePreferredDownload(CNode node, CNodeState state) EXCLUSIVE_LOCKS_REQUIRED(cs_main)
      1 static void UpdatePreferredDownload(const CNode node, CNodeState state) EXCLUSIVE_LOCKS_REQUIRED(cs_main)
$ curl -s https://patch-diff.githubusercontent.com/raw/bitcoin/bitcoin/pull/19053.patch | \
      grep -E '^.static.*(GetFetchFlags|UpdatePreferredDownload)'
-static void UpdatePreferredDownload(CNode* node, CNodeState* state) EXCLUSIVE_LOCKS_REQUIRED(cs_main)
+static void UpdatePreferredDownload(const CNode& node, CNodeState* state) EXCLUSIVE_LOCKS_REQUIRED(cs_main)
-static uint32_t GetFetchFlags(CNode* pfrom) EXCLUSIVE_LOCKS_REQUIRED(cs_main) {
+static uint32_t GetFetchFlags(const CNode& pfrom) EXCLUSIVE_LOCKS_REQUIRED(cs_main) {

@maflcko maflcko merged commit 01b45b2 into bitcoin:master Jun 4, 2020
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 4, 2020
…ithin net_processing.{h,cpp}

8b3136b refactor: replace CNode pointers by references within net_processing.{h,cpp} (Sebastian Falbesoner)

Pull request description:

  This PR is inspired by a [recent code review comment](bitcoin#19010 (comment)) on a PR that introduced new functions to the net_processing module. The point of the discussion was basically that whenever we pass something not by value (in the concrete example it was about `CNode*` and `CConnman*`) we should either use
  * a pointer (```CType*```) with null pointer check or
  * a reference (```CType&```)

  To keep things simple, this PR for a first approach
  * only tackles `CNode*` pointers
  * only within the net_processing module, i.e. no changes that would need adaption in other modules
  * keeps the names of the variables as they are

  I'm aware that PRs like this are kind of a PITA to review, but I think the code quality would increase if we get rid of pointers without nullptr check -- bloating up the code by adding all the missing checks would be the worse alternative, in my opinion.

  Possible follow-up PRs, in case this is received well:
  * replace CNode pointers by references for net module
  * replace CConnman pointers by references for net_processing module
  * ...

ACKs for top commit:
  MarcoFalke:
    ACK 8b3136b 🔻
  practicalswift:
    ACK 8b3136b

Tree-SHA512: 15b6a569ecdcb39341002b9f4e09b38ed4df077e3a3a50dfb1b72d98bdc9f9769c7c504f106456aa7748af8591af7bb836b72d46086df715ab116e4ac3224b3b
maflcko pushed a commit to maflcko/bitcoin-core that referenced this pull request Jun 8, 2020
…tx_verify.{h,cpp}

b00266f refactor: replace pointers by references within tx_verify.{h,cpp} (Sebastian Falbesoner)

Pull request description:

  This PR gets rid of another unnecessary use of raw pointers, similar to PR bitcoin#19053 (see also issue bitcoin#19062 where useful commands for finding potential candidates are listed) but in the tx verification module.

  For the functions `CalculateSequenceLocks()` and `SequenceLocks()`, the  `prevHeights` vector parameter type is changed to be passed as a reference. Note that there were no checks for null pointers -- if one would pass `nullptr` to one of the functions, the following line would immediately lead to a crash:
  https://github.com/bitcoin/bitcoin/blob/dcacea096e029a02a937bf96d002ca7e94c48c15/src/consensus/tx_verify.cpp#L32

ACKs for top commit:
  Empact:
    Code Review ACK bitcoin@b00266f

Tree-SHA512: 0eb71591467905434082029128bdca4df94988c372af40dca325654f6c002c72a00c73776cb5e72d6de2b2f218649211a5dbf19300a2e01f1841d6034e0f01e0
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 8, 2020
…tx_verify.{h,cpp}

b00266f refactor: replace pointers by references within tx_verify.{h,cpp} (Sebastian Falbesoner)

Pull request description:

  This PR gets rid of another unnecessary use of raw pointers, similar to PR bitcoin#19053 (see also issue bitcoin#19062 where useful commands for finding potential candidates are listed) but in the tx verification module.

  For the functions `CalculateSequenceLocks()` and `SequenceLocks()`, the  `prevHeights` vector parameter type is changed to be passed as a reference. Note that there were no checks for null pointers -- if one would pass `nullptr` to one of the functions, the following line would immediately lead to a crash:
  https://github.com/bitcoin/bitcoin/blob/dcacea096e029a02a937bf96d002ca7e94c48c15/src/consensus/tx_verify.cpp#L32

ACKs for top commit:
  Empact:
    Code Review ACK bitcoin@b00266f

Tree-SHA512: 0eb71591467905434082029128bdca4df94988c372af40dca325654f6c002c72a00c73776cb5e72d6de2b2f218649211a5dbf19300a2e01f1841d6034e0f01e0
maflcko pushed a commit to bitcoin-core/gui that referenced this pull request Jul 16, 2020
…t_processing.cpp

0c8461a refactor: replace CConnman pointers by references in net_processing.cpp (Sebastian Falbesoner)

Pull request description:

  This is a follow-up to the recently merged PR bitcoin/bitcoin#19053, replacing ~~two more types of~~ one more type of pointer (CConnman) by references to increase the code quality -- pointers should either check for `nullptr` or be replaced by references, and the latter strategy seems to be more reasonable.

  Again, to keep the review burden managable, the changes are kept simple,
  * only tackling `CConnman*` ~~and `BanMan*`~~ pointers
  * only within the net_processing module, i.e. no changes that would need adaption in other modules
  * keeping the names of the variables as they are

ACKs for top commit:
  jnewbery:
    utACK 0c8461a
  MarcoFalke:
    ACK 0c8461a 🕧

Tree-SHA512: 79dc05144bcfb5e0bbc62180285aadcc6199f044fa3016c0f54f7b7f45037415260970037bd63b18fafefb8aef448549dae14b780bafb540fa2373f493a17f71
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jul 18, 2020
…s in net_processing.cpp

0c8461a refactor: replace CConnman pointers by references in net_processing.cpp (Sebastian Falbesoner)

Pull request description:

  This is a follow-up to the recently merged PR bitcoin#19053, replacing ~~two more types of~~ one more type of pointer (CConnman) by references to increase the code quality -- pointers should either check for `nullptr` or be replaced by references, and the latter strategy seems to be more reasonable.

  Again, to keep the review burden managable, the changes are kept simple,
  * only tackling `CConnman*` ~~and `BanMan*`~~ pointers
  * only within the net_processing module, i.e. no changes that would need adaption in other modules
  * keeping the names of the variables as they are

ACKs for top commit:
  jnewbery:
    utACK 0c8461a
  MarcoFalke:
    ACK 0c8461a 🕧

Tree-SHA512: 79dc05144bcfb5e0bbc62180285aadcc6199f044fa3016c0f54f7b7f45037415260970037bd63b18fafefb8aef448549dae14b780bafb540fa2373f493a17f71
jasonbcox pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Nov 19, 2020
…{h,cpp}

Summary:
```
This PR is inspired by a recent code review comment on a PR that
introduced new functions to the net_processing module. The point of the
discussion was basically that whenever we pass something not by value
(in the concrete example it was about CNode* and CConnman*) we should
either use

    a pointer (CType*) with null pointer check or
    a reference (CType&)

To keep things simple, this PR for a first approach

    only tackles CNode* pointers
    only within the net_processing module, i.e. no changes that would
need adaption in other modules
    keeps the names of the variables as they are

I'm aware that PRs like this are kind of a PITA to review, but I think
the code quality would increase if we get rid of pointers without
nullptr check -- bloating up the code by adding all the missing checks
would be the worse alternative, in my opinion.

Possible follow-up PRs, in case this is received well:

    replace CNode pointers by references for net module
    replace CConnman pointers by references for net_processing module
    ...
```

Backport of core [[bitcoin/bitcoin#19053 | PR19053]].

Depends on D8469.

Test Plan:
  ninja all check-all

Reviewers: #bitcoin_abc, jasonbcox

Reviewed By: #bitcoin_abc, jasonbcox

Subscribers: jasonbcox

Differential Revision: https://reviews.bitcoinabc.org/D8470
@theStack theStack deleted the 20200522-refactor-use-cnode-references-within-net_processing branch December 1, 2020 09:58
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants