Re: [PATCH] name-rev: avoid cutoff timestamp underflow

[Johannes Sixt <j6t@kdbg.org>]

Am 23.09.19 um 10:37 schrieb SZEDER Gábor:
> On Sun, Sep 22, 2019 at 11:01:26PM +0200, Johannes Sixt wrote:
>> Huh? For signed cutoff and positive CUTOFF_DATE_SLOP,
>> cutoff - CUTOFF_DATE_SLOP < cutoff is ALWAYS true. Signed interger
>> underflow is undefined behavior and signed integer arithmetic does not
>> wrap around!
>>
>> IOW, the new condition makes only sense today, because cutoff is an
>> unsigned type, but breaks down should we switch to a signed type.
> 
> Yeah, that's what I meant with worrying about signed underflow in the
> commit message.  As long as the cutoff is at least a day later than
> the minimum value of our future signed 'timestamp_t', the condition
> does the right thing.  And considering that oldest time a signed 64
> bit timestamp can represent far exceeds the age of the universe, and
> the oldest value of even a signed 32 bit timestamp is almost half the
> age of the Earth, I wasn't too worried.

Note that commits and timestamps can be forged easily. I'm not worried
that Git does not work "correctly" with forged timestamps (as long as it
is not exploitable); but when it is simple to make foolproof, we should
do it.

BTW, 32-bit timestamps cover just ~135 years (not half the age of
Earth). That's too little for people who want to store historic
documents in a Git repository.

-- Hannes