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

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
19. jonasnick cross-referenced this on Jul 21, 2023 from issue Upstream PRs 1228, 1236, 1243, 1238, 1246, 1247, 1242, 1250, 1244, 1241, 1257, 1226, 1252, 1118, 1245, 1266, 1269 by jonasnick
20. jonasnick cross-referenced this on Jul 21, 2023 from issue Upstream PRs 1228, 1236, 1243, 1238, 1246, 1247, 1242, 1250, 1244, 1241, 1257, 1226, 1252, 1118, 1245, 1266, 1269 by jonasnick

Contributors
jonasnick apoelstra real-or-random hebasto sipa