Georg Brandl

You have two options: * since you read a byte array anyway, use `Handle::read` instead of `read_value` * create a type with the correct length with `ads::make_string_type!` and use that

Yes, that's option 1. Option 2, to compare: ``` ads::make_string_type!(String255, 255); // on toplevel let plc_str: String255 = handle.read_value().unwrap(); let rust_str: String = plc_str.try_into().unwrap(); ``` You might have to `use...

I'd also be interested! One problem is that `structure` generates `std::io::Error`, and `io` is not available in `core`. Either a custom error type needs to be introduced (which can have...

> So, we'd have no_std by default, and std as opt-in. Usually that's combined with `default = ["std"]` to avoid a) breaking and b) having to specify features for the...

Sure!

I don't think `cty` is necessary, `c_void` is available at `core::ffi`. Also, note that the proc-macro crate doesn't need to work on `no_std`, since it's only used at compile time....

@liranringel are you fine with a MSRV of 1.45? Then we could drop proc-macro-hack.

So one unfortunate point is that most of the `byteorder` features used for reading/writing are on `Write/ReadBytesExt`, which is inextricably linked to `std::io` (they inherit from `Write/Read`). We'd have to...

Great, MSRV 1.45 should simplify a bit. > Notice that we can still use ByteOrder to act on u8 slices. Ok, so the internals would then have to differ quite...

That looks correct. There is no need for a feature for "core". > I think we should also have a look at upping the Cargo Rust edition to 2021, maybe?...