--- Log opened Mon Jul 08 00:00:48 2024
00:59 -!- jamesob15 [~jamesob@108.44.248.162] has quit [Ping timeout: 255 seconds]
01:09 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Ping timeout: 268 seconds]
06:09 -!- lbia [~lbia@user/lbia] has quit [Ping timeout: 252 seconds]
07:05 -!- preimage [~halosghos@user/halosghost] has joined #secp256k1
07:15 -!- lbia [~lbia@user/lbia] has joined #secp256k1
08:53 < josie> thestack nickler (since the same approach is used the musig2 PR): in the bip352 and bip327 PRs variable size arrays of fixed size structs are passed as pointers to an array of pointers, e.g., func(secp256k1_pubkey **pks, n_pks), but since we know the size of the structs it seems we could pass them as a pointer to an array, e.g., func(secp256k1_pubkey *pks, n_pks). is the pointer to array of
08:53 < josie> pointers preferred because it gives the caller the most flexibility or is there something else im missing?
08:55 < josie> i suppose in the case of hsort, maybe its more performant to sort an array of pointers in place vs an array of public keys?
09:26 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
09:41 -!- achow101 [~achow101@user/achow101] has joined #secp256k1
09:58 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
09:59 < josie> ah, this post mentions sorting and also that array indexing might be faster with **arr (in addition to generally more flexible for the caller): https://stackoverflow.com/questions/8206014/passing-an-array-of-structs-in-c
10:00 -!- achow101 [~achow101@user/achow101] has joined #secp256k1
10:23 -!- achow101 [~achow101@user/achow101] has quit [Remote host closed the connection]
10:29 -!- achow101 [~achow101@user/achow101] has joined #secp256k1
10:53 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
13:21 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
13:44 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
14:01 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.3.3]
14:09 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
15:31 < theStack> josie: fwiw, an earlier version of #1471 used the "pointer to an array" approach that you mentioned for passing seckeys/pubkeys lists, and it was changed later to "pointer to an array of pointers" (see https://github.com/bitcoin-core/secp256k1/pull/1471#discussion_r1475018645); one of the rationales we had there was that we didn't want to force the users to store the objects in a contiguous memory area, especially avoiding to copy around secret data
15:33 < theStack> but maybe there are other reasons as well (not sure about sorting performance)
15:34 < theStack> (my "I'm not sure what's the right way to do it" statement is still true :P)
20:05 -!- lbia [~lbia@user/lbia] has quit [Ping timeout: 246 seconds]
22:30 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
22:43 < josie> thestack: ah thanks for the link, i vaguely remembered we had talked about this somewhere. with seckeys, point to array of pointers definitely makes sense, since the alternative would require the caller to copy seckeys around
22:52 < josie> for pubkeys and other structs, i think better sorting (moving 8 bytes around vs the entire struct) and allowing the caller to reuse the same initialization when passing the same public key multiple times are strong enough reasons to always prefer pointer to array of pointers
23:06 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
23:08 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has joined #secp256k1
23:34 -!- tromp [~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl] has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
--- Log closed Tue Jul 09 00:00:48 2024