technocreatives / core2 Goto Github PK

Heya! Thank you for all your work on core2, it makes it so much easier to port libraries to no_std environments.

It's been a while since the last release, can you please push a new release to crates.io with the latest changes?

https://docs.rs/crate/core2/0.4.0/builds/501312

[INFO] [stderr]  Documenting core2 v0.4.0 (/opt/rustwide/workdir)
[INFO] [stderr] error[E0635]: unknown feature `read_initializer`
[INFO] [stderr]  --> src/lib.rs:3:64
[INFO] [stderr]   |
[INFO] [stderr] 3 | #![cfg_attr(all(feature = "std", feature = "nightly"), feature(read_initializer))]
[INFO] [stderr]   |                                                                ^^^^^^^^^^^^^^^^
[INFO] [stderr] 

seems that docs.rs runs cargo doc with --features nightly by default, but this feature no longer exists as per rust-lang/rust#42788.

I get this error:

doesn't satisfy `Vec<_>: WriteBytesExt`
doesn't satisfy `Vec<_>: core2::io::traits::Write

I dont understand why since it is implemented in the impl folder...

0.4.0 is shown as the latest release in crates.io

https://crates.io/crates/core2/versions

but 0.4.0 tag is no longer in the codebase

https://github.com/technocreatives/core2/tags

which causes the crates download breakage.

See

There is no check if the buffer is less than the data to be written.

Maybe it should check this case and return ErrorKind::WriteZero?

As a workaround I have to do cursor.write() and then compare the result with the data length like this:

let data = &[1_u8; 2];
match cursor.write(data) {
    Err(_) => Err(MqttFixedHeaderError::WriteError),
    Ok(size) => if size < data.len() {
        Err(MqttFixedHeaderError::WriteError)
    } else {
        Ok(size)
    }
}

Hello!

I'm having some issues porting a std-using library to no-std using core2/bare-io. I am getting some compiler complaints when I attempt to use my now-ported library:

              |    | expected struct `bare_io::error::Error`, found struct `bare_io::Error`
              |    | help: change the output type to match the trait: `Result<(), bare_io::error::Error>`
              |    |

The library code I have ported to use core2 is here. It builds correctly and passes the built-in library tests/benchmarks in both std and no-std mode.

I don't think I did anything fancy when porting to use bare-io.... I just replaced

    std::io::Write,
    std::io::Result as IOResult,

with

    bare_io::Write,
    bare_io::Result as IOResult,

If this is my error and I am using the library incorrectly, I apologize but either way I would welcome any guidance on how to fix this issue. I believe the error originates when an error is attempted to be handled with a ?.... but I believe this sort of error chaining is one of the main purposes for core2. I'd be happy to show the full error trace if there is interest. Thank you for your time!

Hey. I'm trying to add no_std support to rust-bitcoin and your library has been helpful.

We'd like to have an optional feature that worked in no_std with an allocator in using 1.36.0 -- the version alloc stabilized.

But it seems you're using the non_exhaustive attribute, which stabilized in 1.40.0. Would it be possible to accommodate this usecase?

This is more of a question since I don't know its implications. Would it make sense for this crate to re-export std::error::Error when the std feature is enabled so users don't have to do the feature flagging themselves?

https://github.com/technocreatives/core2/blob/d2d4681c13dfef88ac5fe0ced8d3cb98ccdee85c/src/io/buffered.rs#L612-613
https://github.com/technocreatives/core2/blob/d2d4681c13dfef88ac5fe0ced8d3cb98ccdee85c/src/io/buffered.rs#L631-633

copy_from_slice panics if the slices are of different length. The code does not limit self.buf to the correct slice offset and length needed for this call to ever succeed.

I think it should have been something like

self.buf[self.len..][..buf.len()].copy_from_slice(buf);

Maybe it makes sense to grab the implementation for that from the current stdlib code?

Thanks for core2! I was able to port a std::io-using codebase to it very easily.

The one thing I needed that was missing was IoSlice and IoSliceMut, though for my project, I was able to just disable vectored I/O in no_std builds.

I copied your implementation of the BufReader, tested it with new Rust and discovered that it compiles without nightly feature.
Looks like Rust already supports const generic. Details: https://blog.rust-lang.org/2021/02/26/const-generics-mvp-beta.html

Maybe it's time to remove the nightly feature?

Hi, is there anything in particular preventing a v0.3.0 from being released? Using an alpha seems weird and is a bit unergonomic (tooling defaults to 0.0.0 as most recent release instead).

Hi there. I am coming here from the bare-io entry on crates.io. I am writing a driver for the SD Card on the Sipeed Longan Nano RISC-V micro-controller (no-std context). I am trying to provide an implementation of Read, Write and Seek that the FAT FS can use to interface with an SD Card.

I guess I am checking in to check if this crate is actively maintained and if you see any issue with what I am trying to do.

Thanks

What's here is the bare minimum necessary.

Three things I think are high priority:

• Add module documentation
• Fix doctests that don't pass (predominantly in the buffered mod)
• Add example patterns for making crates compatible with core2

If anybody would like guidance on this, please hit me up.