Reader for inputs implementing HasTargetBytes

[rmalmain]

the idea is to safely read over an input by chunks in a lightweight way (see the test for a simple example), by reusing BytesSubInput (that has been renamed to BytesSubInputMut since it contains a mutable reference). it's still in draft state, i think there is room for improvement.

i tried to auto implement HasTargetBytes for all implementors of HasMutatorBytes but not sure if it is the right thing to do: could it make sense to have mutator bytes that are different from target bytes?

also, end_index now makes sure it does not go beyond the end of the subslice with a min, better this or should we return an error instead? (we could do something similar for start_index)

[domenukk]

could it make sense to have mutator bytes that are different from target bytes?

I'd say a SubInput shouldn't really be sent to the target (?) for example

[rmalmain]

I'd say a SubInput shouldn't really be sent to the target (?) for example

I agree on this, the reader was designed to be created and used by the target internally.

[domenukk]

What's the status here? I think you don't want to mix the concept of MutatorBytes (bytes the mutator wants to mutate) and TargetBytes (bytes that the target will eat up) here.

[domenukk]

@rmalmain ping

[rmalmain]

@domenukk pong. i created an intermediate trait that must be implemented by HasMutatorBytes and HasTargetBytes. that way, we can use BytesReader for both. what do you think?

[domenukk]

@domenukk pong. i created an intermediate trait that must be implemented by HasMutatorBytes and HasTargetBytes. that way, we can use BytesReader for both. what do you think?

This doesn't really make sense imho, the use case for mutator bytes and target bytes is quite different. Instead, you should probably make the BytesReader be instantiated using either a u8 slice, or a OwnedSlice, depending on what you need

[domenukk]

Why don't we do something like

impl<'a> ChunkedReader<'a> {
   fn new(&'a [u8]) -> Self {
       ...
   }

?

[rmalmain]

it feels a bit weird to have BytesSubInputMut that has an input as parent and BytesSlice with a byte slice as parent. shouldn't we unify this with the same type as parent @domenukk (and thus the struct naming)?

[domenukk]

it feels a bit weird to have BytesSubInputMut that has an input as parent and BytesSlice with a byte slice as parent. shouldn't we unify this with the same type as parent @domenukk (and thus the struct naming)?

I mean we could have a BytesSliceMut and an extra BytesSubInput, they have different use case IMHO. BytesSubInput specificially exposes HasMutatorBytes. It could maybe wrap a BytesSliceMut then

[rmalmain]

i think it's good now, anything else @domenukk ?

[domenukk]

Some smaller questions remain, but all in all looks good now!

[domenukk]

Ooops I broke it in 1371646 ... @rmalmain take a look at what I tried to do (mainly move the reader etc into bolts and make it more generic), if yo udon't like it undo and merge.

[rmalmain]

i was actually thinking of moving it to bolts, things like BytesSlice look pretty generic already

[rmalmain]

btw i think you forgot a file, no? libafl_bolts/subrange.rs