--- Log opened Thu May 02 00:00:01 2019 00:46 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has joined #rust-bitcoin 00:53 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has quit [Ping timeout: 250 seconds] 01:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 01:06 -!- TamasBlummer1 [~Thunderbi@p200300DD67196B696506B7C4D522E0CB.dip0.t-ipconnect.de] has joined #rust-bitcoin 01:08 -!- TamasBlummer [~Thunderbi@p200300DD67196B336506B7C4D522E0CB.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 01:08 -!- TamasBlummer1 is now known as TamasBlummer 01:17 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 01:21 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 255 seconds] 01:33 < stevenroose> I'm thinking about fancy ways to implement tagged hashes using contexts. 03:02 < stevenroose> https://github.com/rust-bitcoin/bitcoin_hashes/pull/42 03:02 < stevenroose> nice PR number for an experimental one :D 03:07 < real_or_random> andytoshi: is there a particular reason that we typically have as_mut_ptr() in our structs in secp256k1-rust? I feel using slices woild be cleaner for the public API and internally you can still get the pointer from the slice for FFI 05:03 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #rust-bitcoin 06:38 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has joined #rust-bitcoin 07:20 < andytoshi> real_or_random: what would slice return? 07:20 < andytoshi> a ffi pointer and a &[T] are completely different objects no matter what T is 07:22 < andytoshi> these structures are all opaque. we do not want to expose their internals in the public API 07:43 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 07:51 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 08:14 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 08:18 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 08:25 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 08:32 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 08:32 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 08:35 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has quit [Remote host closed the connection] 08:44 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 08:45 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 09:23 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 09:57 < real_or_random> okay yep, agreed. I'm asking more and more stupid questions about our library in the recent days lol 10:00 < real_or_random> andytoshi: no but the origin of this thought was the no-std where we have SerializedSignature ... here a slice makes indeed more sense, I think 10:02 < real_or_random> currently the PR proposes a get_data_as_mut_ptr(), this is later fed into ffi::secp256k1_ecdsa_signature_serialize_der(). here we could indeed just return a slice in the public interface 10:02 < real_or_random> or at least make get_data_mut_ptr not so public 10:06 < real_or_random> of course, the situation with a real FFI pointer representing an opaque object is entirely different, you're right. not relevant to slices but even there, we throw away rust's borrowing guarantees when giving out raw mutable FFI pointers, no? 10:38 < stevenroose> +1 for #[doc(hidden)] every method containing `ptr`.. 11:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 256 seconds] 12:36 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 13:19 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 13:24 < andytoshi> +1 to #[doc(hidden)] 13:24 < andytoshi> real_or_random: the only reason to use those functions is in an ffi context where rust's borrowck won't help you and where you'd need to cast to a rawptr anyway 13:25 < andytoshi> I don't understand what you're proposing about a slice vs `SerializedSignature` 13:25 < andytoshi> we already impl Index on it which lets you use it as a slice 13:25 < andytoshi> and Borrow<[u8]> iirc 13:30 < real_or_random> raw ptr: I'm talking about something like https://doc.rust-lang.org/std/ptr/struct.NonNull.html 13:31 < real_or_random> and slice: my question is why does SerializedSignature need to provide a get_data_mut_ptr to the public instead of a slice? 13:34 < real_or_random> (not sure if my messages arrived, repeating...) 13:35 < andytoshi> real_or_random: it does provide slicing 13:35 < andytoshi> agree, there's not really a good reason to provide get_data_mut_ptr as well 13:35 < real_or_random> ok, they arrived ^^ 13:36 < andytoshi> oh, it's only AsRef<[u8]>. iirc there was more 13:37 < andytoshi> i'm not sure how slice-like that'll make SerializedSignature by itself 13:37 < real_or_random> no idea, i'd need to check too 13:37 < andytoshi> but my understanding was that it'd give us things like &serialized_sig[..] 13:37 < andytoshi> will try in the playground 13:38 < andytoshi> oh it also impls `Deref` with target [u8] 13:38 < real_or_random> re only useful in a FFI context: a bug in rust-secp256k1-zkp for example could obtain and use a mutable FFI publickey pointer twice. there's nothing that stops this and this would be a bug in rust code 13:39 < real_or_random> oh okay, yes. so there is the slice but we should still avoid the mutable ptr 13:40 < andytoshi> why would it be a bug? 13:40 < andytoshi> btw Deref gets us slice-like behaviour https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9fe042559ced4d2e4369ba466f88d0dd 13:41 < real_or_random> I mean rust-secp256k1-zkp could feed the two mut ptrs into two FFI functions that modify the public key, concurrently 13:41 < real_or_random> that would be a bug 13:41 < andytoshi> yes, that's the nature of raw pointers 13:41 < andytoshi> making the user do their own cast wouldn't help that 13:42 < real_or_random> okay, yeah, depends when you take the pointer 13:43 < andytoshi> i don't see what use an &mut ffi::Object would ever be 13:43 < andytoshi> if you're doing ffi stuff you need rawptrs 13:43 < andytoshi> and if you're not, you shouldn't be using those functions 13:43 < andytoshi> and under no circumstances should you have a slice into opaque libsecp types 13:44 < real_or_random> sorry, I think we're still talking about different things 13:44 < real_or_random> forget about the slices :D the slicing was only relevant to SerializedSignature. I don't want to have slices into libsecp types 13:44 < andytoshi> ok. i don't really understand what you're talking about 13:44 < andytoshi> ok 13:45 < real_or_random> because that does not make sense 13:45 < andytoshi> right 13:46 < real_or_random> for secp types, I was thinking about wrapping them into something like NonNull 13:47 < real_or_random> not sure if this models the ownership correctly, now that I say it again 13:52 < andytoshi> iirc NonNull isn't exposed outside the stdlib 13:56 < real_or_random> https://doc.rust-lang.org/std/ptr/struct.NonNull.html it's there since 1.25... which of course means we can't have it anyway now 13:56 < real_or_random> ah you're saying it's not compatible to no_std? 13:57 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 13:57 < andytoshi> oh, i'm thinking of NonZero maybe 13:57 < andytoshi> oh i see 13:57 < andytoshi> yeah, i was thinking of something else 13:57 < andytoshi> this is just std mocking their ability to mark things non-nullable by exporting some specific type (in this case a non-nullable *mut T) 13:58 < andytoshi> while providing no ability for us to do the same for e.g. hashes 13:58 < andytoshi> s/mocking/flaunting/ 13:58 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 14:03 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 250 seconds] 14:04 < real_or_random> my idea was that if all FFI functions take NonNull instead of raw pointers and obtain the inner ptr only inside the function, then you get more safety. but that reasoning is somewhat flawed. I mean we do this anyway by exposing safe-to-use types like PublicKey. and only if want the FFI call directly, you use a pointer 14:05 < real_or_random> we could still do what I'm saying by having an additional layer between pure FFI and our high-level abstractions. but that seems overkill 14:07 < andytoshi> ah, yep, i understand 14:07 < andytoshi> and agreed, that'd be overkill 14:13 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 14:20 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 14:32 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 14:46 -!- real_or_random [~real_or_r@vmd27468.contaboserver.net] has quit [Ping timeout: 252 seconds] 14:47 -!- real_or_- [~real_or_r@173.249.7.254] has joined #rust-bitcoin 14:47 -!- real_or_- is now known as real_or_random 15:34 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 15:36 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has joined #rust-bitcoin 15:41 -!- willpiers [~willpiers@107-1-237-234-ip-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds] 16:15 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 16:20 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 246 seconds] 17:21 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has joined #rust-bitcoin 17:26 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Quit: gone] 19:34 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has quit [Remote host closed the connection] 20:02 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 21:17 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 21:44 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 21:48 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 22:19 -!- willpiers [~willpiers@38.75.231.30] has quit [Remote host closed the connection] 22:53 -!- willpiers [~willpiers@38.75.231.30] has joined #rust-bitcoin 22:58 -!- willpiers [~willpiers@38.75.231.30] has quit [Ping timeout: 255 seconds] 23:42 -!- ccdle12 [~ccdle12@113x38x63x74.ap113.ftth.ucom.ne.jp] has joined #rust-bitcoin --- Log closed Fri May 03 00:00:01 2019