--- Log opened Tue Aug 20 00:00:45 2019
00:42 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 248 seconds]
01:00 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #rust-bitcoin
03:04 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:05 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
05:02 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 260 seconds]
05:49 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hjgejwmrqsgtbbhb] has joined #rust-bitcoin
05:54 < real_or_random> elichai2: following up on #145
05:54 < real_or_random> I'm not sure either
05:57 < real_or_random> we could even offer the full spectrum of from_slice, try_from_slice, from_array and try_from_array (or other name than "array")
05:57 < elichai2> yeah there's no clear answer here. maybe `parse_compressed([u8; 33]) -> Result<__>` and `parse_uncompressed([u8;64])->Result<__>` and leave the from_slice, i'm not sure about the panicing
05:57 < real_or_random> right, parse_uncompressed is the right name ^^
05:58 < real_or_random> panicing where now?
05:58 < elichai2> in the end we're still stuck with a result... I don't see a way out of it. *maybe* with a private key we can have a `from_array([u8;32])` that panics on 0 and >p and comment this
05:58 < elichai2> "Maybe we should have a from_slice which panics on any form of invalid key and a try_from_slice which returns an option?"
05:59 < real_or_random> hm yeah, maybe try_from_slice is enough?
06:00 < real_or_random> this is more explicit at least... if the user knows what he's doing, then he should at least be explicit about it and call unwrap
06:01 < real_or_random> but I'm also okay with having a from_slice that panics. do you think that's a problem?
06:01 < elichai2> you mean just renaming the current `from_slice` to `try_from_slice`?
06:01 < elichai2> real_or_random: idk, in a private key or a public key?
06:01 < real_or_random> idk, both?
06:03 < elichai2> hmm I don't really see a scenerio where someone knows 100% that what he has is a valid public key and it's not already in a public key object
06:05 < real_or_random> maybe if you read it from disk / your own database
06:06 < real_or_random> but yes, I mean, if we don't feel confident about from_slice, let's stick to try_from_slice maybe?
06:06 < elichai2> yeah
06:06 < real_or_random> for private keys, it's easier at least
06:07 < real_or_random> if you take a random value, you can accept the panic that happens with negligible probability
06:07 < elichai2> and private key generation code should look like: https://gist.github.com/rust-play/03a36b2292b6d812f0e19d7d8457970a
06:07 < real_or_random> (and you can ensure the size)
06:07 < elichai2> but yeah, accepting that it panics if 0 or over n is acceptable
06:08 < real_or_random> ah hmpf but we have from_slice already
06:09 < elichai2> let's remind ourself the original problem :) ZST
06:09 < real_or_random> xD
06:09 < elichai2> this is what caused this conversation lol
06:10 < elichai2> arrays solve the ZST problem without any added conditions
06:10 < real_or_random> ok ok, so I think the current from_slice is fine. we could rename it to try_from_slice and introduce a panicing one but that's a hassle for users, so let's avoid this
06:10 < elichai2> they should have something like `NonNull` but `NonEmpty` lol
06:11 < real_or_random> I also think that adding methods for conversion from arrays is a good idea
06:12 < real_or_random> and I think the from_slice method should check for zero size, and then return a Error. and still we keep the CPtr with the null
06:12 < real_or_random> that means if we miss the code in our wrapper code, we'll get a clean panic instead of UB at least
06:13 < elichai2> by clean you mean by assuming `ARG_CHECK` will call the callback, right?
06:15 < elichai2> i'll tell you my original motivation for having a valid static pointer for ZSTs, it was `memcpy(dest,src,0)` in this call, even though it shouldn't do anything having null/invalid pointer in src/dest is implementation defined
06:15 < real_or_random> yep
06:15 < elichai2> so I wanted to know that I always pass a valid pointer even with len 0
06:18 < real_or_random> do we actually have a memcpy call (or is this just an example)?
06:19 < elichai2> No. In reality libsecp use ARG_CHECK  before anything else. So that'll be fine. It was a general to C trait I use
06:19 < elichai2> But are we fine with panicking if passed a empty slice?
06:20 < real_or_random> no I think we aren't. that's why we should catch this case.
06:21 < real_or_random> I'm just saying, even if we miss to catch such cases, we won't get UB
06:24 < real_or_random> real_or_random: I think my entire point was that I'd prefer to pass NULL and rely on secp256k1 to bail out than passing a non-null pointer to some invalid data
06:40 < elichai2> makes sense
06:47 < real_or_random> elichai2: can you unify this in a single PR? seems cleaner
06:47 < real_or_random> (maybe that's just meant when you said "merge this and #144"
06:54 < elichai2> yeah I guess so, i'll open a third PR that uses null instead of the static and adds the explicit checks
08:24 -!- reallll [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
10:26 < andytoshi> can we push forward on https://github.com/rust-bitcoin/rust-bitcoin/pull/317 ?
10:28 < elichai2> sure, pushed the bumping commit
11:47 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds]
12:03 -!- bzrs [6369393c@99-105-57-60.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection]
12:37 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
12:39 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
13:01 -!- mauz555 [~mauz555@2a01:e35:8ab1:dea0:558:a5a9:64d6:a1d1] has joined #rust-bitcoin
13:13 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 260 seconds]
13:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
14:10 -!- CubicEarth [~CubicEart@c-67-168-3-75.hsd1.wa.comcast.net] has joined #rust-bitcoin
14:20 -!- CubicEarth [~CubicEart@c-67-168-3-75.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds]
17:38 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hjgejwmrqsgtbbhb] has quit [Quit: Connection closed for inactivity]
18:24 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cooapdoquivenlgb] has joined #rust-bitcoin
19:13 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
21:30 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #rust-bitcoin
21:58 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cooapdoquivenlgb] has quit [Quit: Connection closed for inactivity]
22:20 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:21 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
22:28 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection]
22:30 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #rust-bitcoin
23:23 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:24 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin
--- Log closed Wed Aug 21 00:00:46 2019