[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11825: 24.1.50; float-time no longer accepts negative time values

From: Eli Zaretskii
Subject: bug#11825: 24.1.50; float-time no longer accepts negative time values
Date: Sun, 08 Jul 2012 18:32:50 +0300

> Date: Sun, 08 Jul 2012 00:26:47 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> On 07/07/2012 07:57 PM, Eli Zaretskii wrote:
> > are you saying that a time difference can
> > never be negative on such platforms?
> Yes, that's right.
> > What about the case tv_sec = 0
> > in both time values and tv_nsec difference is negative?
> In that case, timespec_sub returns the
> minimum possible time value, namely zero,
> since time_t is unsigned.

??? Really???  Then using these facilities safely and portably will be
extremely inconvenient.  E.g., to express something like

  T1 = T2 + T3 - T4

instead of a simple

  t1 = timespec_add (t2, timespec_sub (t3, t4));

one would need something like

  if (timespec_cmp (t3, t4) < 0)
      struct timespec tem1 = timespec_sub (t4, t3);

      if (timespec_cmp (t2, tem1) < 0)
         /* error -- no way to express negative time */
         t1 = timespec_sub (t2, tem1);
    t1 = timespec_add (t2, timespec_sub (t3, t4);

Am I missing something?

If I'm right, and if there's no way to get better facilities, then at
the very least this should be prominently explained in systime.h.
Right now, this comment, for example:

  /* Put into DEST the result of adding SRC1 to SRC2, or of subtracting
     SRC2 from SRC1.  On overflow, store an extremal value.  */

doesn't come anywhere close to a hint that "an extremal value" could
mean zero when SRC1 < SRC2.  It's very easy to write buggy code
without a clear understanding of this fact, and never find those bugs
in testing, if the system happens to use a signed type for time_t.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]