--- Log opened Tue Jun 07 00:00:45 2022 07:15 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1 08:22 -!- sigurdson[m] [~sigurdson@2001:470:69fc:105::2:25f5] has joined #secp256k1 11:45 -!- real_or_- [~real_or_r@user/real-or-random/x-4440763] has joined #secp256k1 11:46 -!- fjahr_ [sid374480@id-374480.uxbridge.irccloud.com] has joined #secp256k1 11:46 -!- glozow_ [sid453516@user/glozow] has joined #secp256k1 11:50 -!- real_or_random [~real_or_r@user/real-or-random/x-4440763] has quit [Ping timeout: 248 seconds] 11:50 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has quit [Ping timeout: 248 seconds] 11:50 -!- glozow [sid453516@user/glozow] has quit [Ping timeout: 248 seconds] 11:50 -!- glozow_ is now known as glozow 14:29 < real_or_-> Is there a deep reason why we pass structs always by reference? The compiler should be able to figure out the most efficient way in most cases even with pass-by-value. 14:30 -!- jb55 [~jb55@user/jb55] has quit [Quit: jb55] 14:30 < real_or_-> I think one reason may be that avoiding copies makes it easier to clean secrets from the stack (though we don't do this currently...) 14:31 < real_or_-> (wait, what's wrong with my nick... Oo) 14:31 < sipa> I think it's a practice I adopted a long time ago, to avoid passing structs by value in C in general. I can't remember the exact reasons. 14:31 < real_or_-> ok yes, that's what I figured 14:31 < sipa> I vaguely remember something about calling conventions. 14:33 < halosghost> though I have no idea of the actual reason in this codebase, passing structs by-reference is heavily preferred in many C codebases for the sake of performance 14:33 < halosghost> so, it wouldn't shock me if it descends from that ☺ 15:03 < sipa> Yeah, it may have been due to a belief (unsure if correct, even at the time) that some compilers and/or calling conventions would put returned structs on the stack, resulting in an additional copy operation in the caller to put it in place. 15:06 < sipa> And I still kind of feel icky about returning structs in C, actually, because I don't actually know what it'll be compiled to. 15:10 < halosghost> sipa: do you feel more comfortable with returned pointers, or is your preference then straight to in/out-values? 15:10 < halosghost> s/values/params/ 15:10 < sipa> Eh, depends on the situation. 15:10 < sipa> You can't return pointers to local variables, for example. 15:11 < halosghost> indeed 18:08 -!- halosghost [~halosghos@user/halosghost] has quit [Quit: WeeChat 3.5] --- Log closed Wed Jun 08 00:00:46 2022