Post ADfjjEB6YHigygldwm by hughcb@sc.sigmaris.info
 (DIR) More posts by hughcb@sc.sigmaris.info
 (DIR) Post #ADdhpJUD8nHSxCYglc by calebccff@fosstodon.org
       2021-11-21T22:24:52Z
       
       0 likes, 0 repeats
       
       finished my first rust program - an MVP (minimum viable product) at least. feels good. although i feel like i hit a few issues which are mostly due to a lack of experience with rust and that kinda sucks.
       
 (DIR) Post #ADdhpclvR9jwldzbW4 by calebccff@fosstodon.org
       2021-11-21T22:24:53Z
       
       0 likes, 0 repeats
       
       biggest issue is i have to call some library which wraps poll(2), the function im calling takes an array of file descriptors, but rust arrays enforce size-constraints at compile time and i dont know how many file descriptors I'll have.
       
 (DIR) Post #ADdhpiGwzEWnpJXx4K by calebccff@fosstodon.org
       2021-11-21T22:24:54Z
       
       0 likes, 0 repeats
       
       my approach is to just hard-code a limit and set a maz size for the array but this feels like a bad hack.
       
 (DIR) Post #ADdivDfRmtmEbCC6m8 by migratory@banana.dog
       2021-11-21T22:37:08Z
       
       0 likes, 0 repeats
       
       @calebccff you should just be able to use a slice (&[T]) on the rust side, and use `.as_ptr()` and `.len()` when passing to C
       
 (DIR) Post #ADf0Dp7x91dWMywca0 by migratory@banana.dog
       2021-11-21T22:37:49Z
       
       0 likes, 0 repeats
       
       @calebccff if you need to actually store a dynamic number of elements on the Rust side, that's what `Vec<T>` is for
       
 (DIR) Post #ADf0DpgL5B8s5d25B2 by calebccff@fosstodon.org
       2021-11-22T13:25:42Z
       
       0 likes, 0 repeats
       
       @migratory thanks for the tip, im calling an existing wrapper (nix::io::poll iirc) which takes an array so I don't think either of those approached quite work
       
 (DIR) Post #ADfhHXKpXADGNJz6rg by hughcb@sc.sigmaris.info
       2021-11-22T21:28:11Z
       
       0 likes, 0 repeats
       
       @calebccff @migratory If referring to https://docs.rs/nix/0.23.0/nix/poll/fn.poll.html looks like this does take a slice of PollFds, so it should be possible to have a Vec<PollFd> and pass a slice of it by e.g. `poll(&mut my_vec, my_timeout)`. Here's a similar example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ab632fa07cd5cf3decc28bac6f0e4673
       
 (DIR) Post #ADfiXsYwTgRgnawSgK by calebccff@fosstodon.org
       2021-11-22T21:42:22Z
       
       0 likes, 0 repeats
       
       @hughcb @migratory h u h, so just passing a mutable reference to a vector will have poll() still treat it as an array?what/why is this behaviour?
       
 (DIR) Post #ADfjjEB6YHigygldwm by hughcb@sc.sigmaris.info
       2021-11-22T21:55:35Z
       
       0 likes, 0 repeats
       
       @calebccff @migratory What gets passed to poll() is a "slice", which consists of a pointer to some memory where a number of elements are stored sequentially, and a count of how many elements are there, and that's all poll() needs to work with.A slice isn't quite the same as an array, slices don't own memory, they refer to memory "elsewhere" (in this case, memory owned by the Vec). IME arrays aren't used very much in Rust, due to the size-known-at-compile thing. Vec and slices are used instead.
       
 (DIR) Post #ADfnQJW6sUhDqmpT3g by hughcb@sc.sigmaris.info
       2021-11-22T22:01:57Z
       
       0 likes, 0 repeats
       
       @calebccff @migratory When starting Rust, it took me a while to understand how slices worked. As someone who worked a bit with C and C++ before, seeing the data layout on https://cheats.rs/#references-pointers-ui helped - a "regular slice reference" shown there is just a ptr and a len. And lower down the page in "Standard Library Types", a Vec is just a ptr, capacity and len. And it reveals how a slice can be got easily from a Vec just by taking the Vec's ptr and len, and passing them to another function.
       
 (DIR) Post #ADfnQK6yfQBdh84uWW by calebccff@fosstodon.org
       2021-11-22T22:37:00Z
       
       0 likes, 0 repeats
       
       @hughcb @migratory huh, awesome. thanks for the explanation