Because of the provisioned input in commit 9f57b69 one of the fuzzing tests will fail until #2529 gets fixed.

More context: With this fuzzing approach, I also wanted to test for inconsistencies when doing multiple parsing rounds (multiple read-writes). Parsing an object, writing it back, and parsing it again should result in the same struct that was parsed in the first round. By doing this we can also ensure that no unexpected panics are occurring either.

So i simplified and condensed the fuzzing for the newc format into a singular test. What it does:
It tries to parse any generated fuzzing input. If an error occurs, which is not unexpected as even unparseable inputs are generated, the test will just skip to the next input. If an input is parseable though the test will make sure it can be written back to an byte array and parsed back again. The reparsed object then must be identical to the first one. This makes sure that both directions (parsing and write-back) do not alter the underlying object.
Additionally any panics will also be caught.

Added a second commits which adds more checks when parsing cpio records.
I ran just short of 4 million different executions in about 30 minutes locally without encountering more errors.
The fuzzing is reproducible by running the following in the pkgs directory:

GOMAXPROCS=4 GOMEMLIMIT=4GiB go test -fuzz=FuzzReadWriteNewc

Codecov Report

Base: 73.86% // Head: 73.88% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (f697078) compared to base (137076d).
Patch coverage: 100.00% of modified lines in pull request are covered.

@@            Coverage Diff             @@
##             main    #2528      +/-   ##
==========================================
+ Coverage   73.86%   73.88%   +0.01%     
==========================================
  Files         403      403              
  Lines       40977    40979       +2     
==========================================
+ Hits        30269    30278       +9     
+ Misses      10708    10701       -7     

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

quick question. We don't want only fuzzy tests, I assume? IOW there is value in the regular tests, since they run quickly and catch simple errors, and then fuzzing tests as well?

I would see fuzzing as an addition to the unit tests. But you are right, in newc_test.go one of the the unit tests is very close to the fuzzing tests. But only doing fuzzing would come with some disadvantages. You can use the unit test testvalues as fuzzing seed inputs (which are executed every time), but debugging a fuzzing test can be finicky due to the nondeterministic selection of inputs. And you only want to fuzz in some cases. This was not clear in my previous commit in which rewrote every test to fuzz.

For example: If we have a fuzzing tests (which parses, writes-back, parses, ...) the only "randomly" generated input is the parsed byte-array and not the struct object itself, therefore focusing on a realworld-cases.

I added the fuzzing inputs, which caused panics in the parsing function, as seed inputs. This does two things:

1. These are run everytime we executing go test in the CI
2. Coverage is improved as the additional parsing checks i included are now hit as well

This is pretty nice to get the baseline coverage of the tests up.