On Wed, Apr 15, 2015 at 12:17:36PM -0400, Justin Keller wrote:
> Is there a reason for "step = leap"?
It's there to not change the behavior when a leap second occurs, the
clock still needs to be stepped. I guess it could be optimized a bit,
if it used "if (unlikely(leap || tk->xtime_sec >= time_ma
On Wed, Apr 15, 2015 at 10:31:54PM +0100, One Thousand Gnomes wrote:
> On Wed, 15 Apr 2015 17:41:28 +0200
> Miroslav Lichvar wrote:
> > larger value. When the maximum is reached in normal time accumulation,
> > the clock will be stepped back by one week.
>
> Which itself is open to exploits and d
On Wed, 15 Apr 2015 17:41:28 +0200
Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
Even ext4 is still broken for 2038.
> larger value. When the maximum is reached in normal t
Is there a reason for "step = leap"?
On Wed, Apr 15, 2015 at 11:41 AM, Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in an unexpected state by not checking integer o
On Wednesday 15 April 2015 17:41:28 Miroslav Lichvar wrote:
> On systems with 32-bit time_t, it seems there are quite a few problems
> that applications may have with time overflowing in year 2038. Beside
> getting in an unexpected state by not checking integer operations with
> time_t variables, s
On systems with 32-bit time_t, it seems there are quite a few problems
that applications may have with time overflowing in year 2038. Beside
getting in an unexpected state by not checking integer operations with
time_t variables, some system calls have unexpected behavior, e.g. the
system time can'
6 matches
Mail list logo
