Make position of * in pointer declarations in include/ consistent #1252

pull jonasnick wants to merge 1 commits into bitcoin-core:master from jonasnick:asterisk changing 6 files +86 −86
  1. jonasnick commented at 7:41 pm on March 28, 2023: contributor
  2. Make position of * in pointer declarations in include/ consistent 3d1f430f9f
  3. apoelstra commented at 7:52 pm on March 28, 2023: contributor
    I think we should move it the other direction, so the * is part of the type and not part of the name.
  4. jonasnick commented at 7:25 am on March 29, 2023: contributor
    I went with the traditional convention as used in the C standard. I’d agree with you if the position of * was entirely arbitrary. But making * part of the name makes more sense in C because it applies to the variable and not the type. For example, char* foo, bar; declares foo to be a pointer to char and bar to be a char.
  5. real-or-random approved
  6. real-or-random commented at 11:31 am on March 29, 2023: contributor

    I think they’re arguments for either side. But yeah, we should make it consistent.

    utACK https://github.com/bitcoin-core/secp256k1/pull/1252/commits/3d1f430f9f32d45885b0a10b448c0f15386c423d

    I would ACK the other variant as well.

  7. hebasto commented at 12:47 pm on March 29, 2023: member

    I think we should move it the other direction, so the * is part of the type and not part of the name.

    +1 on that. Especially in the case when this repo is a subtree in other C++ project (like Bitcoin Core), which uses the same convention.

  8. sipa commented at 2:58 pm on April 7, 2023: contributor

    utACK 3d1f430f9f32d45885b0a10b448c0f15386c423d. I have not verified these are the only instances where changes would need to be made.

    In general, concept ACK on making these types consistent across the codebase. I have a slight preference for * hugging the variable rather than the type, because it’s closer to how the C semantics for types actually work, but consistency is more important than bike shedding this if there is disagreement.

  9. apoelstra commented at 3:23 pm on April 7, 2023: contributor
    utACK 3d1f430 from me too. I also value consistency more than either specific choice.'
  10. real-or-random merged this on Apr 8, 2023
  11. real-or-random closed this on Apr 8, 2023

  12. sipa cross-referenced this on Apr 10, 2023 from issue ElligatorSwift + integrated x-only DH by sipa
  13. sipa referenced this in commit e1552d578e on Apr 11, 2023
  14. sipa referenced this in commit c981671e9b on Apr 14, 2023
  15. hebasto referenced this in commit 49c52ea2b1 on May 13, 2023
  16. RandyMcMillan referenced this in commit 3cc75121b3 on May 27, 2023
  17. vmta referenced this in commit e1120c94a1 on Jun 4, 2023
  18. vmta referenced this in commit 8f03457eed on Jul 1, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 03:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me