wcampbell

Could you give more context? Is this for `unsquashfs`, `FilesystemWriter`, or `FilesystemReader`?

> Merged into the branch, thanks a bunch @rbran :) > > I think the remaining issue is MSRV. I wonder if limiting the MSVR policy to only `default-features` is...

> This Christmas I was thinking about this API 😂 > > Maybe it's better to not access the filesystem directly using `std::fs` or `nix`. Instead having a trait that...

> > This Christmas I was thinking about this API 😂 > > Maybe it's better to not access the filesystem directly using `std::fs` or `nix`. Instead having a trait...

@rbran I tried the instructions at https://github.com/AFLplusplus/LibAFL/tree/main/libafl_libfuzzer at some point. But I had issues and didn't have time to file an issue.

> Maybe there is something wrong with my setup, but the fuzzer is only able to get a few hundred executions per second. Even on my somewhat modern computer I...

> I suppose having the Deku assertions being transformed from panics into errors could improve fuzzing in the future, let me know what you think. What do you mean by...

> Sorry, I meant the deku assertions, like in https://github.com/wcampbell0x2a/backhand/blob/master/backhand/src/dir.rs#L22 > > They usually result in panic, and not Result::Error, which limits the fuzzer capability to differentiate invalid input and...

> > They shouldn't result in a panic: https://github.com/sharksforarms/deku/blob/d1827d1b4ddf34def616263f0a642de9a58b1653/deku-derive/src/macros/deku_read.rs#L550C11-L550C11 > > If you remove the 255 limit from the fuzzer, you get this panic: > > ``` > thread ''...

> > Yes that sneaky unwrap shouldn't exist > > I thought about that, actually this unwrap should exist. > > An error should be returned when trying to add...