In message <[email protected]>, Michael Deckers writes: > For one thing, IEEE float values contain infinities and > NaNs, and since the POSIX interfaces accept time_t values > as inputs, ths system code would have to deal with them.
timeval contains bogus combinations of tv_sec and tv_usec and a lot of code does not even notice... 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. > 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. > The timestamps of computer operating systems are often > used in a way where mainly the sequence of increasing > values is important, not so much their absolute value. That is why I added the "run_time()" version also. > Comparing IEEE floating point values holds its surprises > because values may be incomparable, In which case they are not valid timestamps, and you get EINVAL if in a library or whatever you asked for in your own code. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
