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
