fattime: make the test code check beyond 32-bit time_t limits

[jeffpc_josefsipek.net]

Summary

On systems that have a 64-bit time_t, the test code now exercises the whole
range of fattime. To do this, this commit...

1. replaces the call to random() with two calls to arc4random() to generate a 33-bit number of seconds in order to cover the entire range of fattime [1970,2107]. (32-bits stops just short - in January 2106.) On systems with 32-bit time_t, the extra bits are discarded and only the time_t expressible range is tested.
2. casts time_t values passed to printf as longs and changes the format string to match.

Now, the test code builds, runs, and exercises what it can (i.e., the whole
fattime range or the 32-bit time_t subset of it) on both 32-bit and 64-bit
time_t systems.

[imp]

sys/kern/subr_fattime.c

309

I'd be tempted to use (intmax_t) here instead of long. and a corresponding '%jd' format.

[imp]

sys/kern/subr_fattime.c

284

why just one bit? Why not, say 16, which gets you dates in the next 8 million years... Hmmm, that seems like overkill... but 2 would get you dates through 2234 or so and would provide better coverage. 3 would get us through 2488. 4 through the year 3000 (which may be a nice round number to stop at).

[jeffpc_josefsipek.net]

sys/kern/subr_fattime.c

284

The only reason not to use more bits is that the loop is less likely to terminate quickly. With one extra bit it's ~128/272 chance. With 2 extra bits, it is ~128/544. And so on. (128 = number of years expressible by fattime, 272, 544, ... number of years from 1970 until the max time_t value randomly generated)

This is test code, so it shouldn't matter either way as long as it isn't a large number of extra bits. I'm fine with certainly anything <= 4 extra bits, but can be convinced of more.

309

Sure, I'll change it.

[jeffpc_josefsipek.net]

generate 36-bit time_t values & use intmax_t for cast