sozu-proxy/circular

stream abstraction designed for use with nom

circular's Issues

Add some optional glue code to the `bytes` crate

It would be nice if this crate would provide optional glue code to the bytes crate, with which I mean implementing the bytes::{Buf,BufMut} traits, to allow easier integration with other existing code, e.g. poll-buf-utils. It is probably a good idea to support a wide range of bytes crate versions, as the Buf & BufMut traits are present in that crate since almost the first versions, and haven't changed at all.

miri reporting UB

When trying to run my program with miri, it reports UB, however with the note that "the Stacked Borrows rules it violated are still experimental". This minimal example UBs according to miri. I don't know how to make it more minimal unfortunately without investing too much time into it. I'm not using circular directly, it's a transitive dependency through rc-zip.

use rc_zip::prelude::*;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let f = &include_bytes!("../tests/data/Test.docx")[..];
    let a = f.read_zip_with_size(f.len() as u64).unwrap();
    let entry = a.by_name("word/document.xml").unwrap();
    let mut doc = xml::EventReader::new(entry.reader());
    let _ = doc.next();
    Ok(())
}

Cargo.toml:

[package]
name = "ziptest"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
rc-zip = "2.0.1"
xml-rs = "0.8.16"

Is this a valid concern or a false positive?

Test.docx (but any Word document should do I guess)

Output:

Full output: output.txt

Add method to consume bytes without shifting buffer ?

Hi @Geal ,

The consume method shifts data if >= half the buffer. I'm using the circular crate as a fixed-position buffer (for multi-threading) and need to control when data is moved.

Would you be OK for adding a new method (consume_noshift or something ilke that) which just adds cnt without shifting data ? I can provide a patch :)

Why does the Buffer have a capacity element

The memory element has a capacity() and a len() method (I think memory.len() might be the appropriate equivalent to self.capacity), why is it necessary to have another struct element capacity in the struct Buffer? This seems like duplicate book-keeping to me, why is that necessary?

see also: example of reduction