1216714 - Implementation-defined behavior in TimeStamp difference operator when the newer operand is unknown

Status: NEW

(Core :: XPCOM, defect)

Description

[Karl Tomlinson (:karlt)]

BaseTimeDuration docs say "Negative durations are allowed, meaning the end is
before the start."  The TimeDuration docs also hint at the possibility of
negative durations.

TimeStamp docs say it is possible to
"compute a difference between two TimeStamps to get a TimeDuration" and the
documentation of operation-(const TimeStamp) says
"Compute the difference between two timestamps. Both must be non-null."
I think it is reasonable to expect this to behave sensibly when b > a.

It looks like the code aims to provide sensible behavior (returning values
such as INT64_MIN when it thinks it detects underflow) but depends on
implementation-defined behavior converting uint64_t values greater than
INT64_MAX to int64_t.

https://hg.mozilla.org/mozilla-central/annotate/1a157155a4fe0074b3d03b54fe9e466472c2cd56/mozglue/misc/TimeStamp.h#l478

This issue existed in the original implementation of bug 484921.

In N3936 4.7 Integral conversions:

"If the destination type is signed, the value is unchanged if it can be
represented in the destination type (and bit-field width); otherwise, the
value is implementation-defined."

Comment 1

[Karl Tomlinson (:karlt)]

From N3936:

1.3.10
[defns.impl.defined]
implementation-defined behavior

"behavior, for a well-formed program construct and correct data, that depends
on the implementation and that each implementation documents"

https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html

"The result of, or the signal raised by, converting an integer to a signed
integer type when the value cannot be represented in an object of that type
(C90 6.2.1.2, C99 and C11 6.3.1.3).

For conversion to a type of width N, the value is reduced modulo 2^N to be
within range of the type; no signal is raised."

https://msdn.microsoft.com/en-us/library/e9s326kw.aspx

"Unsigned values are converted in a way that preserves their value and is not
representable directly in C. The only exception is a conversion from unsigned
long to float, which loses at most the low-order bits. Otherwise, value is
preserved, signed or unsigned."

Bjarne Stroustrup says "a conversion is value-preserving if you can convert a
value and then convert the result back to its original type and get the
original value."

So both implementations define the behavior that is wanted here.

This may therefore be wontfix, but I'm guessing it also wouldn't be too hard
to fix with TimeDuration::FromTicks(uint64_t).