
"Clive D.W. Feather" wrote on 1998-10-08 19:14 UTC:
In message <199810052044.NAA14428@shade.twinsun.com>, Paul Eggert <eggert@twinsun.com> writes
Perhaps I'm paraphrasing you incorrectly; still, I am extremely uncomfortable with the idea that the C standard should impose an upper limit on the quality of the clock.
It shouldn't. However, that doesn't mean that it can't put a limit on Standard access to the clock. Thus a design that limited defined precision to 1ns, but didn't forbid an fs or as field would be reasonable.
If there really is a hard-core fraction of attosecond fanatics in WG14, I'd be happy to replace xtime with struct xtime { xtime_sec_t sec; xtime_subsec_t subsec; } #define SUBSEC_PER_SEC ... /* subseconds per seconds */ I just tried to do the technically correct thing before the politically correct thing. Nobody is ever going to need subnanosecond resolution from xtime_get. Leaving the subsec encoding open will make portable programming more cumbersome and less readable. If you want to provide for direct hardware counter access (perfectly reasonable idea), then the "right thing"[TM] to do is to make an interface that looks precisely like clock() (just with a different name), but that gives access to an integer real-time counter instead of a process-time counter. This is what people interested in subnanosecond timing might want to use, but as I said before, these things are much more likely to be implemented in inline assembler or via direct I/O access anyway, because they are incredibly non-portable by their very nature. There is no chance to get even tens of nanosecond timing done in a portable way, so portable subsecond nanosecond timing really is science fiction. It is an "interesting" balance of design to require on one side the standard to provide provisions for unrealistic subnanosecond clock readings, and on the other size to provide no delay function at all (which will force authors of portable software to use inefficient wait loops that continuously read the clock until it is too late). But hey, if it makes the committee happy, ... Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>