--- Log opened Thu Nov 06 00:00:30 2025
07:59 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-kernel
09:00 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
09:00 < stickies-v> ping TheCharlatan 
09:00 < TheCharlatan> pong
09:00 < stickies-v> not bad. sorry, just wanted to see if you have any thoughts on my comments from yesterday
09:01 < stickies-v> https://gnusha.org/bitcoin-kernel/2025-11-05.log
09:03 < TheCharlatan> yeah, I just used the fixed array for output with a known size. I think it is a little clearer, because the developer can just always allocate 32 bytes of contiguous memory and then call the function. But yeah, maybe that is not really that beneficial.
09:13 < stickies-v> I think it is nice that certain classes of functions always behave the same, e.g. the `_count` and `_equals` functions, and having the same for `to_bytes` would be nice to simplify clients, I think
09:14 < stickies-v> but I haven't done any measurements
09:15 < TheCharlatan> yeah, either using to_raw() to disambiguate or btck_WRiteBytes` would make sense here.
09:25 < stickies-v> yeah, that would be a solution too
09:27 < stickies-v> and if we're doing that, i was thinking if it made sense to also indicate endianness in the function names. e.g. `_le_to_bytes()` instead of `_to_bytes()`
09:27 < stickies-v> unsure if too handhold-y
13:02 < TheCharlatan> I don't think that is necessary. All the bytes streams we surface at the moment are in their serialization order.
15:03 < stickies-v> mm fair enough, i guess if it's consistent there's no need to complicate that
--- Log closed Fri Nov 07 00:00:31 2025