state (e.g. secret
key) will be predictable (I'm not really sure if unpredictability is
needed here — I've read some discussions where it was mentioned, and
it seems it is). That's why it uses new randomness, but also the
updated diff preserves and increments 8 bits of the previous
generation number to avoid repeating it too soon.
--
Dmitry Chestnykh
https://www.codingrobots.com
Here's another version: it starts with a random 31-bit integer and
then for subsequent allocations sets 23 random bits and incremented 8
bits from the previous generation number, so it's guaranteed to not
repeat for at least 256 allocations (suggested by Kai Antweiler).
-Dmitry
Index: src/sys/ufs
/k)
>From the common sense department: keep the current version, which does
simple increment, just make sure it won't overflow.
--
Dmitry Chestnykh
https://www.codingrobots.com
. Otherwise, probably it's better to keep the
current incrementing.
>> signed integer, it may overflow, causing undefined behavior
>
> The development of OpenBSD/univac is running way behind schedule.
:-) Speaking of signed integers, does it really need to be signed?
--
Dmitry Chestnykh
https://www.codingrobots.com
positive integer in [1,
INT_MAX] range, not equal to the previous generation number.
--
Dmitry Chestnykh
https://www.codingrobots.com
Index: src/sys/ufs/ffs/ffs_alloc.c
===
RCS file: /cvs/src/sys/ufs/ffs/ffs_alloc.c,v
retrieving revision
