C machine

[Alan Mycroft]

In article <7159 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>[gwyn at 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?