--- Log opened Wed Aug 07 00:00:32 2019 01:36 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1 01:36 -!- jonatack [6dca6b93@109.202.107.147] has joined #secp256k1 03:08 -!- jonatack [6dca6b93@109.202.107.147] has quit [Remote host closed the connection] 03:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 04:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 04:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 04:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 04:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 04:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 04:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 05:22 -!- jonatack [6dca6b93@109.202.107.147] has joined #secp256k1 05:23 -!- jonatack [6dca6b93@109.202.107.147] has quit [Remote host closed the connection] 09:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer] 10:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 10:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:26 -!- nkohen [~nkohen@2601:282:4101:9356:a1ee:9437:66b5:23b4] has quit [Remote host closed the connection] 10:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 10:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 10:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 11:09 < elichai2> In the `secp256k1_context_preallocated_create` function docs it says ` The caller must provide a pointer to a rewritable contiguous block of memory of size at least secp256k1_context_preallocated_size(flags) bytes, suitably aligned to hold an object of any type.` what does `aligned to hold an object of any type` mean? what exactly should the pointer be aligned to? 11:11 < sipa> sufficiently aligned for anything :) 11:12 < elichai2> lol, is this pointer size? size_t size? something different :) 11:12 < sipa> _all_ types 11:14 < andytoshi> elichai2: neither rust nor C provide any way to get the alignment you need 11:15 < andytoshi> although the return values from libc malloc() will be appropriately aligned 11:15 < sipa> since C11 there is the alignof operator 11:15 < andytoshi> libsecp hardcodes the value 16 which is likely to work on all platforms in use today 11:15 < andytoshi> can you write alignof(anything) though? 11:16 < sipa> ah, no 11:17 < elichai2> really? malloc returns pointers that are aligned for all types? hu 11:17 < sipa> yes 11:17 < andytoshi> yes, because it has to be able to allocate anything :P 11:18 < sipa> i think we could (for now) provide better guarantees though; e.g. we never store anything but char/pointers and ints up to 64 bits in the preallocated area 11:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 11:18 -!- reallll [~belcher@unaffiliated/belcher] has joined #secp256k1 11:18 < sipa> and alignment is never more than the size of the data itself, so i think that on <=64-bit platforms, you never need an alignment above 8 bytes 11:18 < andytoshi> in rust, this would guarantee that the alignment of the whole struct was the max of those things' alignment 11:18 < andytoshi> is that true in C? 11:19 < andytoshi> at most the max* 11:19 < sipa> yes 11:19 < sipa> alignments are always powers of 2 11:19 < sipa> so the larger of any two alignments is always valid for both 11:20 < sipa> oh! 11:20 < sipa> C11 has max_align_t 11:20 -!- roconnor [~roconnor@host-45-58-228-96.dyn.295.ca] has joined #secp256k1 11:20 < sipa> which is the largest-alignment fundamental data type 11:21 < roconnor> andytoshi: you can write alignof(max_align_t) as "max_align_t is a type whose alignment requirement is at least as strict (as large) as that of every scalar type. " 11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 11:21 < sipa> roconnor: in C11. 11:21 < roconnor> oops too slow. 11:21 < sipa> libsecp256k1 is C89 :) 11:22 < andytoshi> fwiw elichai2 cares about this for the purpose of the rust bindings 11:22 < roconnor> Maybe the one calling libsecp256k1 is using C11? :D 11:22 < andytoshi> so if we can find a way to do it in rust that'll suffice 11:23 < elichai2> we could even be conservative and use alignment 16 as max alignment, afaik in rust there's no max alignment: https://play.rust-lang.org/?gist=43f8b0c0726a646f171186e605ef2ec8 11:24 < andytoshi> lol 11:24 < andytoshi> but yeah, that's also my understanding, even for builtin types .. in particular the rust docs won't commit to any alignment for fat pointers or unsized types (neither of which C has) 11:24 < andytoshi> https://doc.rust-lang.org/reference/type-layout.html is mum 11:28 < elichai2> andytoshi: the nice thing is that whatever alignment we chose we could easily type safely enforce it: https://play.rust-lang.org/?gist=615a6726e5c6d55ddcb674387a816ae6 11:29 < andytoshi> so, i don't believe that either of your asserts are guaranteed to pass 11:29 < andytoshi> but we could certainly take a `*mut [A]` rather than `*mut [u8]` 11:30 < andytoshi> actually, https://doc.rust-lang.org/reference/type-layout.html does claim that alignment of n means "the address will be a multiple of n", though it doesn't say what that actually means 11:31 < andytoshi> and ISTR in C the win32 API would do stuff like using the low bits of pointers to store flag data 11:31 < roconnor> Is there any way to test alignment of a pointer in C? AFAIK the best you can do is trust that malloc has given you a well alligned pointer can manually count the offset from there. 11:32 < andytoshi> it may be that this was just technically UB, and ms could do that because they controlled the compiler chain 11:32 < sipa> andytoshi: ocaml stores integers and pointers in the same internal datatype, with integers encoded as (2*X + 1) 11:33 < sipa> so that their garbage collector can recognize pointers 11:33 < elichai2> why wouldn't those asserts always pass? a pointer to a array/slice of type A should be aligned as A is, I think 11:33 < elichai2> `The alignment of &[T] is the word size.` 11:33 < andytoshi> elichai2: because arithmetic on pointers is meaningless and i don't understand why a cast to usize should translate pointer guarantees into arithmetic guarantees 11:34 < andytoshi> unless someone can give me C&V describing the semantics of a pointer cast to usize 11:34 < andytoshi> iirc the only guarantee is that you can cast back and you'll get the same pointer 11:34 < sipa> C&V? 11:34 < andytoshi> heh, sorry. chapter and verse 11:34 < andytoshi> that's what poeple would say on comp.lang.c 11:34 < sipa> ah 11:34 < elichai2> andytoshi: that's why I also added the second assert https://doc.rust-lang.org/std/primitive.pointer.html#method.align_offset 11:34 < andytoshi> when asking for a C standard reference 11:35 < andytoshi> if one assert fails a second assert won't help you :P 11:36 < elichai2> lol, it was just an example, I think the first place I saw people casting pointers to usize to check alignment is in: https://github.com/rust-lang/hashbrown/blob/master/src/raw/sse2.r 11:36 < elichai2> *.rs 11:37 < andytoshi> ok, but those are debug_asserts, where i think it's reasonable to get false negatives in theory 11:37 < andytoshi> or on esoteric arches 11:39 < elichai2> yeah, I'm not trying to prove that it's correct. on rust 1.36^ we have the `align_offset` for us i'll try to see if there's any defined good way to do assertions. until then we first need to even define what alignment do we plan to enforce heh 11:43 < andytoshi> let's just use 16 like upstream does 11:43 < andytoshi> i commented on https://github.com/rust-bitcoin/rust-secp256k1/issues/138 to this effect 12:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 12:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 12:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 12:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 12:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 12:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 12:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 12:47 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 12:55 < real_or_random> yeah, you can't check if a pointer is aligned in C 12:55 < real_or_random> which is somewhat stupid because alignment is required anywhere ^^ 12:57 < sipa> is having an unaligned pointer not UB in the first place? 12:57 < real_or_random> no, just deferencing it is UB 13:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 13:08 < real_or_random> (we could also let rust compile the C code in C11 mode. but yes, using 16 is more reasonable...) 13:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 13:10 -!- reallll is now known as belcher 13:10 < andytoshi> rust doesn't compile the C 13:10 < andytoshi> just links with it 13:11 < andytoshi> well, i mean, we do have a build script in the rust library, and we could modify that to force C11 13:11 < andytoshi> but it's just calling out to the system C compiler 13:12 < real_or_random> sure 13:13 < andytoshi> and generally the more we try to do weird things, the more we regret it :). we have travis tests on windows and actual users targeting wasm 13:13 < andytoshi> so who knows what options are available 13:22 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 13:25 < real_or_random> yes, I was not suggesting this seriously 15:40 -!- Rinku420 [~Rinku420@tcmson2003w-lp130-02-174-93-95-244.dsl.bell.ca] has joined #secp256k1 15:44 -!- Rinku420 [~Rinku420@tcmson2003w-lp130-02-174-93-95-244.dsl.bell.ca] has quit [Quit: Peer reset by connection] 16:06 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bsihzsmbdqhsuctf] has quit [Quit: Connection closed for inactivity] 17:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 18:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 18:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #secp256k1 19:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 19:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 248 seconds] 19:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds] 20:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 20:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1 --- Log closed Thu Aug 08 00:00:33 2019