It's not clear to me what cargo fuzz cmin will or won't do with files it encounters that exceed the maximum length specified in a -max_len parameter. I'd hope it would attempt to split them, and failing that, mutate them to be smaller (with the output set of overlength files, sorted in descending order of length, being not larger than the input set); but the documentation doesn't make it clear whether overlength files are processed at all. This is relevant because at https://github.com/Pr0methean/zip-next, I'm experimenting to find the optimal -max_len, and my current seed corpus looks like this (files with readable names were reverted after a previous cargo fuzz cmin because Git detected them as renames):
hennickc@f8ffc25e7f6e zip-next % ls -ltrS fuzz/corpus/seed
total 5408
-rw-r--r-- 1 hennickc staff 0 Mar 13 16:25 empty_nonzip
-rw-r--r-- 1 hennickc staff 46 Mar 13 15:13 5f991f472f30d0d2de41379b1e552075c9d6bbd4
-rw-r--r-- 1 hennickc staff 94 Mar 13 15:13 386c90fc081ebb1fc2e4c035702c826c8c0d4190
-rw-r--r-- 1 hennickc staff 95 Mar 13 18:19 empty.zip
-rw-r--r-- 1 hennickc staff 98 Mar 13 18:19 empty_Stored.zip
-rw-r--r-- 1 hennickc staff 100 Mar 13 18:19 empty_Deflated.zip
-rw-r--r-- 1 hennickc staff 107 Mar 13 18:19 empty_Zstd.zip
-rw-r--r-- 1 hennickc staff 110 Mar 13 18:19 empty_Stored_zipcrypto.zip
-rw-r--r-- 1 hennickc staff 112 Mar 13 18:19 empty_Bzip2.zip
-rw-r--r-- 1 hennickc staff 117 Mar 13 15:13 ddc4a8f54379469121804348ba02c1e1bae9769d
-rw-r--r-- 1 hennickc staff 119 Mar 13 18:19 empty_Zstd_zipcrypto.zip
-rw-r--r-- 1 hennickc staff 124 Mar 13 15:13 82d4c17bfb3c31659948bf97d41dbf7f0e807db1
-rw-r--r-- 1 hennickc staff 148 Mar 13 15:13 b4e69657c69ea5962bff09bccb5f45e71ac36c5a
-rw-r--r-- 1 hennickc staff 153 Mar 13 15:13 1ad19d9eb2edaee71afc210e839d8dac697654b1
-rw-r--r-- 1 hennickc staff 168 Mar 13 15:13 ba88e4885adc019b8957d87850b77bb0f428264d
-rw-r--r-- 1 hennickc staff 212 Mar 13 15:13 63375baec121be15dc5d06d1d882aa6c9c0b745c
-rw-r--r-- 1 hennickc staff 224 Mar 13 15:13 1c3f4d3727b6afd4ea3259594f919cc73d97c1f0
-rw-r--r-- 1 hennickc staff 236 Mar 13 15:13 edef730bd6973a0fd2ca2ecff4798fffebc88d5d
-rw-r--r-- 1 hennickc staff 250 Mar 13 15:13 1169657c580a09df745a1263f6ada5753b506d55
-rw-r--r-- 1 hennickc staff 462 Mar 13 15:13 caf508c6a628b756588d8c049a8c79dd7c115b37
-rw-r--r-- 1 hennickc staff 562 Mar 13 15:13 07aab9b3e2134f049734136429a880e484149262
-rw-r--r-- 1 hennickc staff 724 Mar 13 15:13 00092feab48ca8bb1adbcb363778e92bbc08c838
-rw-r--r-- 1 hennickc staff 908 Mar 13 15:13 9420c66a08d0f90099a2d4dc1960a7906c3b50b6
-rw-r--r-- 1 hennickc staff 908 Mar 13 15:13 3b45b4528549f20c243af17eb507c073bd3fa116
-rw-r--r-- 1 hennickc staff 1241 Mar 13 15:13 d897ffd132e1f32f985dc0b7986867fdf792220f
-rw-r--r-- 1 hennickc staff 2670507 Mar 13 15:13 80162ba110916e671872b1ebd077721f51e325c7
It's not clear to me what
cargo fuzz cminwill or won't do with files it encounters that exceed the maximum length specified in a-max_lenparameter. I'd hope it would attempt to split them, and failing that, mutate them to be smaller (with the output set of overlength files, sorted in descending order of length, being not larger than the input set); but the documentation doesn't make it clear whether overlength files are processed at all. This is relevant because at https://github.com/Pr0methean/zip-next, I'm experimenting to find the optimal-max_len, and my current seed corpus looks like this (files with readable names were reverted after a previouscargo fuzz cminbecause Git detected them as renames):