16:40 <re_irc> <James Logan> chrysn: the only way I've found to guarantee that a crate is really no-std compatible (and stays that way) is to add a separate no-std test crate and build that test crate for a target with no OS as part of testing, and require passing tests to merge to main

16:41 <re_irc> <James Logan> example test crate for no-std check here: https://github.com/jlogan03/catnip/tree/jlogan/bitfield/test/test_no_std

16:42 <re_irc> <James Logan> and the ci workflow that actually builds it to check compatibility is here https://github.com/jlogan03/catnip/blob/jlogan/bitfield/.github/workflows/github-actions.yaml#L29

16:43 <re_irc> <James Logan> note that example uses LTO in order to also check panic-never compatibility, but you may not want that for testing no-std compatibility as thoroughly as possible

16:44 <re_irc> <James Logan> ^ (uses LTO because otherwise panic branches do not get optimized out, and compilation will always fail with panic-never)

16:44 <re_irc> <chrysn (@chrysn:matrix.org)> Nice, thanks, I'll use that!

16:49 <re_irc> <James Logan> yeh it's sort of a personal experiment, because I didn't want to use a giant software stack for running a daq on a local network

16:49 <re_irc> <James Logan> and I'm a complete newb w.r.t. networking so I'm not making any claims about security

16:50 <re_irc> <chrysn (@chrysn:matrix.org)> Hm, the whole trick still does depend on having a platform for which we know that there is no std library for it, right?

16:51 <re_irc> <James Logan> yeah which is where the "none" for the target comes in - no OS -> no std

16:52 <re_irc> <James Logan> so all that test crate is going to do is show that it can be compiled for a platform that could not possibly have the standard library

16:53 <re_irc> <chrysn (@chrysn:matrix.org)> Fair enough. I kept being worried that they add std to platoforms where it makes no sense at all (IMO wasm32-unknown-unknown should not have a std library), but given that "unknown" != "none", hopefully that'd be safe.

16:53 <re_irc> <James Logan> yeah that example crate also specified #[no_std]

16:54 <re_irc> <James Logan> you can also specify #[no_std] in a library, and crates that depend on that library can either have or not have std and it doesn't break them

16:54 <re_irc> <chrysn (@chrysn:matrix.org)> Hm ... if I do rely on a platform not having a std for sure, I can probably just build the main library crate for that platform, with no need for an extra test crate (because I don't do the panic-never tests).

16:54 <re_irc> <James Logan> could do, as long as you have a way to actually run it

16:55 <re_irc> <James Logan> which is sort of the hangup

16:55 <re_irc> <chrysn (@chrysn:matrix.org)> I just want to prove that it builds under forced no_std -- I don't see how it should build and then not run.

16:56 <re_irc> <James Logan> good point

16:59 <re_irc> <chrysn (@chrysn:matrix.org)> Might not be your precise solution I'm using, but either way -- thanks, after this chat I can move forward (and have something to suggest, eg, to wasmi (https://github.com/paritytech/wasmi/issues/374#issuecomment-1189624740)).

21:00 <re_irc> <explodingwaffle101> been writing / procrastinating writing an i2c device driver, wondering if there is a better way to deal with registers and their fields. https://github.com/tkeksa/lis2dh12/blob/master/src/lib.rs#L633 started off by using the methods from here, which is nicer than the bare e-h methods but still requires a load of const bitmasks, and still not great for dealing with anything that isn't just a true/false. went...

21:00 <re_irc> ... looking for other solutioms- found packed_struct, bounded-registers, i2c-reg, but not really a fan of any of them. been wondering- would a macro to generate an api sort of like the one svd2rust makes for pacs be a good way to go about it? might be overcomplicating this, i dunno

21:06 <re_irc> <henrik_alser> explodingwaffle101: might wanna take a look at the just released https://docs.rs/mycelium-bitfield/latest/mycelium_bitfield/index.html

21:10 <re_irc> <explodingwaffle101> that looks very nice. will take a closer look

21:10 <re_irc> <GrantM11235> I've never used it, but I think device-driver (https://crates.io/crates/device-driver) does what you are talking about

21:12 <re_irc> <explodingwaffle101> ...that looks even nicer 😅 i swear i spent like 2 hours looking for stuff. i guess my google-fu is not strong enough