--- Log opened Wed Jan 19 00:00:34 2022 04:25 -!- halosghost [~halosghos@user/halosghost] has quit [Ping timeout: 240 seconds] 04:38 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1 04:50 -!- gnusha [~gnusha@user/gnusha] has joined #secp256k1 04:50 -!- Topic for #secp256k1: libsecp256k1 development discussion | https://github.com/bitcoin-core/secp256k1 | Channel logs: http://gnusha.org/secp256k1 04:50 -!- Topic set by real_or_random [] [Tue Jun 1 01:19:08 2021] 04:50 [Users #secp256k1] 04:50 [ ajonas ] [ fanquake ] [ jonasschnelli_] [ nickler ] [ sgiath ] 04:50 [ andytoshi ] [ FelixWeis ] [ kanzure ] [ pink_sarco ] [ sipa ] 04:50 [ Apocalyptic] [ fjahr ] [ kaushik ] [ real_or_random] [ siv2r[m] ] 04:50 [ ariard ] [ ghost43 ] [ kcalvinalvin ] [ realtbast[m] ] [ stickies-v] 04:50 [ BlueMatt ] [ glozow ] [ laanwj ] [ robertspigler ] [ uasf ] 04:50 [ BlueMatt[m]] [ gnusha ] [ lightningbot ] [ robot-dreams ] [ waxwing ] 04:50 [ cfields ] [ halosghost ] [ luke-jr ] [ rockhouse ] [ windsok ] 04:50 [ darosior ] [ harding ] [ MatanHamilis ] [ roconnor ] [ yakshaver ] 04:50 [ DeanGuss ] [ jesseposner] [ meshcollider ] [ RubenSomsen ] 04:50 [ dr-orlovsky] [ jnewbery ] [ michaelfolkson] [ sanket1729 ] 04:50 [ elichai2 ] [ johnzwen- ] [ Nebraskka ] [ sebx2a ] 04:50 -!- Irssi: #secp256k1: Total of 52 nicks [0 ops, 0 halfops, 0 voices, 52 normal] 04:50 -!- Channel #secp256k1 created Wed May 19 12:44:13 2021 04:52 -!- Irssi: Join to #secp256k1 was synced in 143 secs 06:46 < roconnor> Want to double check with folks here: Moving secp256k1_fe_one from field_impl.h to field.h is good right? 06:46 < roconnor> context: https://github.com/bitcoin-core/secp256k1/pull/899#discussion_r787622020 06:50 < sipa> I don't see a reason why not. 07:05 < halosghost> roconnor: out-of-interest: why do you say that you've found it to be frowned-upon to return structures in C? 07:18 < roconnor> personally it is a combination of the fact that is it never done in libsecp256k1 and the fact that VerifiableC doesn't support that operation. I suspect it is illegal is old enough C standards. 07:20 < roconnor> I was browsing stack overflow and there does seem to be wide agreement on this frowning, though the reasons seem to amount mostly to worries about structures ending up being placed on the stack especially in embedded environments. 07:20 < roconnor> which I don't find that compelling since it isn't required to use the stack. 07:21 < roconnor> There also seem to be some worries about calling conventions and having them mixed up between compilers. 07:21 < roconnor> That said, I return structures all the time in my programs. 07:44 < halosghost> roconnor: as far as I know, that's always been valid in C (going back at least to C99 if not C89 and K&R) 07:44 < roconnor> huh 07:44 < halosghost> and, the main argument I've heard against it is that if you're returning structs by-value, there's a good chance you're copying them a lot; and in that case, returning/modifying pointers-to-struct is going to be faster 07:45 < halosghost> but that's a “rule” that is incredibly case-dependent 07:45 < halosghost> however, that libsecp doesn't do it at all is a totally valid reason to avoid it here ☺ 07:45 < halosghost> (then again, libsecp does use in-out parameters, which is not a convention I've seen used much at all elsewhere) 07:46 < halosghost> VerifiableC looks cool; I vaguely recall seeing this somewhere previously; will need to dive in deeper 07:46 < roconnor> I'm trying to use it to verify the verification routines of libsecp 07:50 < halosghost> bbiab 07:50 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 2.5-rc1] 08:19 < roconnor> according to the venerable user529758, returning sturctures was standardized in C89: https://stackoverflow.com/a/12234227 08:22 < sipa> I thought there were performance issues with it in general, as it can involve several copies. 08:23 < roconnor> maybe. But RVO is allowed in C. 08:23 < sipa> Right, but the ABI may not. 08:24 < roconnor> ya calling conventions seems to be a sticky issue that I haven't really digested. 08:24 < sipa> I guess if you're talking about internal static functions, the compiler can choose not to obey the ABI, as the function might not even be materialized in its source code form. 08:25 < sipa> halosghost: libsecp256k1 mostly uses output arguments first, then input arguments. 08:26 < sipa> For the API that's even spelled out explicitly: https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L12L24 08:43 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1 08:44 < halosghost> roconnor: sounds like a worthy endeavour 08:44 < halosghost> (more formally-verified software ≡ more better afaiac) 08:47 < roconnor> either that or ossifies secp256k1 because no one will be allowed to change anything without a formal proof of correctness. 08:50 < halosghost> there's a point at-which security-critical infrastructure significantly benefits from such a requirement 08:50 < halosghost> definitely raises the bar for entry/innovation; but it does so intentionally (to avoid accidentally destroying security guarantees) 08:50 < halosghost> plus, I think we're a ways off from that anyway ☺ 11:34 < real_or_random> my life would certainly be simpler in a world where noone is making changes to secp256k1 :P 11:34 < real_or_random> so please go ahead with formal verification :P 11:37 < halosghost> lol 14:43 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 2.5-rc1] --- Log closed Thu Jan 20 00:00:35 2022