It doesn't make sense to fuzz times in the past, as Bitcoin Core will refuse to start in the past.
Fix that and also remove a sanitizer suppression, which would be hit in net_processing in ProcessMessage:
if (addr.nTime <= 100000000 || addr.nTime > nNow + 10 * 60)
addr.nTime = nNow - 5 * 24 * 60 * 60; // <-- Here
This changes the format of fuzz inputs. Previously a time value was (de)serialized as 40 bytes, now it is 32 bytes.
Apperently this is not enough to remove the sanitizer suppression, see fuzzer fails for large values - the problem is that nTime is of type uint32_t, which can't go beyond the year 2106, whereas the fuzzed nNow is int64_t.
Thanks, done!
Code Review ACK fa7238300c18938cdf627cacfc58d4b81602417f
I think we don't lose a lot of generality by restricting ConsumeTime() like this, since it basically used for setting the mock time, where times outside the range 2000-2100 aren't realistic.
Being able to remove the sanitizer suppression for all of net_processing seems more important.
2000-2100 aren't realistic
Indeed. For now. If someone fixes the 2106 bug, then at the same time the fuzzed range can be extended.