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

[Eli Zaretskii]

> Date: Sun, 08 Jul 2012 00:26:47 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 11825@debbugs.gnu.org
> 
> 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 */
      else
         t1 = timespec_sub (t2, tem1);
    }
  else
    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.