--- Log opened Fri May 14 00:00:54 2021
01:23 < real_or_random> secp256k1_nonce_functions have a void* data parameter, but in ecdsa_sign we pass a const void* (and we cast the const away). isn't this a bug?
01:29 < sipa> iirc there is nothing wrong with casting away constnesz, as long as either no mutations happen, or the object pointed to is not const
01:30 < sipa> it's a weird discrepancy though
01:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
01:31 < sipa> the caller of ecdsa_sign chooses both the nonce fn and the data passed to it, and is responsible for passing a compatible pair
01:32 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1
01:35 < real_or_random> roconnor: same thing happens in secp256k1_gej_eq_x_var which is used in ECDSA verification. but ok, the speedup is still negligible
01:35 < real_or_random> but I believe it's worth a PR (or an issue) because it would improve the internal docs
01:36 < real_or_random> sipa: I don't think that's true. Why should the user even be allowed to pass a function that modifies data?
01:37 < real_or_random> sipa: If the user passes a nonce function that modifies data, then they'll be lying to the compiler because the prototype promises that the data won't be written to, no?
01:38 < real_or_random> so that should be UB
01:38 < real_or_random> *the prototype of ecdsa_sign
01:38 < sipa> no
01:39 < sipa> a const pointer does not mean it"s illegal to modify
01:39 < sipa> iirc it really doesn't mean anything
01:39 < sipa> a const *object* cannot be modified, and doing so would be UB
01:40 < sipa> but a non-const object, taken a pointer to, made const, and then having that const removed, and then modified through that, is perfectly fine
01:41 < real_or_random> ok I agree with this
01:41 < real_or_random> but still, wouldn't it be cleaner if ecdsa_sign simply took a non-const pointer?
01:42 < real_or_random> it's at least confusing
01:42 < sipa> yes, definitely
01:42 < sipa> it's weird that the types don't match
01:43 < real_or_random> this change would touch a heavily used function but would make it strictly more callable? . is this a thing we could just change? I believe yes
01:44 < sipa> i think so
01:46 < real_or_random> (btw, found with clang -Weverything which generates some noise but apparently also some useful stuff)
02:06 < real_or_random> hm I was consistently const in very early revisions but then changed by this commit https://github.com/bitcoin-core/secp256k1/pull/299/commits/05732c5a5f781d49972659d8f59e5262ff026ce8
02:14 < real_or_random> luke-jr: I know this is 6 years ago. ^^ but if you can remember (or recreate) your thoughts, that will be helpful :)
07:29 < luke-jr> real_or_random: I think the idea was to accept const pointers from callers, but if it was non-const, don't impose constness on callbacks
07:30 < luke-jr> usually const is more callable than non-const
07:44 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
07:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds]
07:49 -!- lukedashjr is now known as luke-jr
11:06 < real_or_random> luke-jr: I don't understand, "int foo(void* p)" gives the caller strictly more freedom than "int foo(const void* p)"?
11:39 < real_or_random> anyway I created https://github.com/bitcoin-core/secp256k1/issues/945 , where we could discuss further
11:43 < real_or_random> roconnor: and https://github.com/bitcoin-core/secp256k1/issues/946
14:30 < luke-jr> real_or_random: no, void* can't be passed a const*
14:30 < luke-jr> real_or_random: const void* can be passed either const* or anything void* would take
14:30 < luke-jr> ?
14:32 < luke-jr> real_or_random: compile and look at warnings on http://dpaste.com/DTLXCBTV3
14:33 < luke-jr> only passing const int* to void* warns
14:33 < luke-jr> both int* and const int* pass into const void* fine
19:30 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1
19:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
--- Log closed Sat May 15 00:00:55 2021