On 2012-01-21 15:54, Poul-Henning Kamp wrote:
timeval contains bogus combinations of tv_sec and tv_usec and a lot of code does not even notice...
Yes, in contrast to IEEE binary floating point values where each and every bit pattern belongs to one of the classes FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, or FP_ZERO.
I already specified that you get EINVAL if it is not a valid floating point number. I may have to be more specific than "valid" but I really don't see this a problem, considering how trivial and fast this is to check, compared to the math needed to get to, for instance UTC.
Yes, a specification had to clarify what the term "valid floating point number" means. More to the point: IEEE arithmetic adheres to a well-defined (and sophisticated) computational model, and I believe users would expect that model to be followed if time_t was an IEEE float. Case in point: difftime() should react in the standard way on arguments that are signalling or quiet NaNs -- even if the programers don't care or don't know, their debuggers may rely on it. Of course, you are right that all this can be reasonably specified (with some effort). May be this is what BSD users REALly want to be in <time.h> (or in <math.h>). You probably know best how to find out.
> Moreover, IEEE floating point operations depend on certain > environmental settings (eg, rounding modes and enabled > traps) and it is not clear whether a system call must or > can use those of the caller in every circumstance. I'm not sure I can see how it can become relevant, given a good quality library implementation.
Example questions: does difftime() set the inexact flag? does it use the rounding mode in force at the call? (People do interval arithmetic by executing their algorithm twice with different rounding modes.) Michael Deckers. _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
