tests: add Vec + String fuzz harnesses

[0xllx0]

Adds a basic fuzzing test harness using cargo-fuzz to run randomized tests against the Vec and String types.

[zeenix]

Adds a basic fuzzing test harness using cargo-fuzz to run randomized tests against the Vec type.

I'm a bit puzzled as to what is being tested here. 🤔 Typically fuzzing is useful for finding out issues with parsers and decoders (i-e something that handles external data) but Vec is just keeping things as they are in the memory.

[0xllx0]

Adds a basic fuzzing test harness using cargo-fuzz to run randomized tests against the Vec type.

I'm a bit puzzled as to what is being tested here. 🤔 Typically fuzzing is useful for finding out issues with parsers and decoders (i-e something that handles external data) but Vec is just keeping things as they are in the memory.

Definitely, this harness was the simplest one to open the conversation about introducing fuzzing into the library. It would probably be more useful in a String fuzzer, or any other types that utilize parsing (like you mentioned).

If you have a particular type in mind, I'd be happy to write a harness for it, and add it to this PR.

[zeenix]

t would probably be more useful in a String fuzzer,

Not really. It doesn't do any parsing either. It just stores whatever you give it.

If you have a particular type in mind, I'd be happy to write a harness for it, and add it to this PR.

Tbh, I don't think it's a good idea to look for problems for a solution. I'm sure there is some API in this crate that could possibly make use of fuzzing but I don't know it.

[0xllx0]

Not really. It doesn't do any parsing either. It just stores whatever you give it.

The reason I suggested String is because it does "parse" in a certain sense: https://github.com/rust-embedded/heapless/blob/main/src/string/mod.rs#L245

It decodes from UTF-16 and UTF-8, which is currently handled by the implementation in the char primitive. While the backing storage is just the Vec and VecView, there is a step involved to ensure that String has a proper encoding.

Tbh, I don't think it's a good idea to look for problems for a solution. I'm sure there is some API in this crate that could possibly make use of fuzzing but I don't know it.

That's an interesting way to frame my contribution to review and test the library.

[zeenix]

The reason I suggested String is because it does "parse" in a certain sense: https://github.com/rust-embedded/heapless/blob/main/src/string/mod.rs#L245

It decodes from UTF-16 and UTF-8, which is currently handled by the implementation in the char primitive. While the backing storage is just the Vec and VecView, there is a step involved to ensure that String has a proper encoding.

I actually thought about that but core::str::from_utf8 doing the actual checking and we rely on it to do its job. If we want to fuzz anything here, it would be in core/std, not here.

Tbh, I don't think it's a good idea to look for problems for a solution. I'm sure there is some API in this crate that could possibly make use of fuzzing but I don't know it.

That's an interesting way to frame my contribution to review and test the library.

I'm sorry for my bluntness. Fuzzing in general is extremely useful so I appreciate what you're trying to do. What I said, was more about how I feel about the conversation is going so far here between us, rather than a criticism of your contribution in general.

If you could find a good use for fuzzing in this library, I'd be very happy to help you add fuzzing for that here. I just currently don't see a place for it.

Perhaps I'm wrong and that's why I'm keeping this open for now. Perhaps other maintainers would have a better idea than me and can suggest a use. 🤷

[0xllx0]

I'm sorry for my bluntness. Fuzzing in general is extremely useful so I appreciate what you're trying to do. What I said, was more about how I feel about the conversation is going so far here between us, rather than a criticism of your contribution in general.

No worries, I understand where you're coming from now.

Perhaps I'm wrong and that's why I'm keeping this open for now. Perhaps other maintainers would have a better idea than me and can suggest a use.

Sounds good to me, I'm happy to leave this up if for no other reason than to serve as a reference point for future contributors who would want to introduce fuzz testing.

I actually thought about that but core::str::from_utf8 doing the actual checking and we rely on it to do its job. If we want to fuzz anything here, it would be in core/std, not here.

This makes sense to me as well. If there ever was a decision to use a custom UTF-8/UTF-16 parser, the fuzz tests might be more useful here.

I'll review the core/std test suite to see if they have any fuzz harnesses around their UTF-8/UTF-16 parsers.

Thanks for the feedback.