Path: utzoo!mnetor!uunet!mcvax!ukc!eagle!icdoc!cam-cl!am From: am@cl.cam.ac.uk (Alan Mycroft) Newsgroups: comp.lang.c Subject: Re: C machine Message-ID: <1131@jenny.cl.cam.ac.uk> Date: 29 Jan 88 11:30:35 GMT References: <461@auvax.UUCP> <28700025@ccvaxa> <7159@brl-smoke.ARPA> Reply-To: am@cl.cam.ac.uk (Alan Mycroft) Organization: U of Cambridge Comp Lab, UK Lines: 38 Keywords: printf, ptrdiff_t, time_t In article <7159@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >[gwyn@brl-smoke.ARPA] >If you don't like using a type other than a known basic type, you can of >course coerce the ptrdiff_t into a long via a (long) cast, but seldom is >this necessary or useful. (It is necessary if you're going to printf() >the value of a ptrdiff_t.) >>I suppose that there is no equivalent to %p for pointers for >>ptrdiff_t? > >Why should there be? printf( "%ld", (long)(p2 - p1) ); To reopen this discussion, I agree that Gwyn's code works, but it essentially lies in the deprecated category in that a future ANSI-C standard could add extra types, e.g. long long int, and on implementations with ptrdiff_t = long long int; then (long)(p2-p1) would fail. The problem is that there is no portable way to to pass ptrdiff_t, clock_t to printf(). Even more problematic: has anyone on the ANSI committee tried writing a STRICTLY CONFORMING program which accurately prints cpu time (a la clock()) to a file (say in centi-secs or to 2 decimal places)? Perhaps printf("%t", (time_t)...)? The trouble is that time_t may be either integral or floating. Thus code like printf("%ld", (long)(clock()*100/CLK_TCK)); MAY work, or the *100 may overflow. Now there is no guarantee that using double arithmetic will work either: time_t may be more precise (32bits) than a f.p mantissa. Thus printf("%f", (double)clock() * 100.0 / CLK_TCK); is probably the best that one can do. I still feel uneasy about the gratuitous use of floating point there though. I concede that someone may think of a very good reason as to why time_t may be floating (the draft says arithmetic) and anyway it is asctime()'s job to decode it. However I think that clock_t could be sensible restricted to be integral since its job is to *count* CLK_TCK's anyway. Views?