Re: time(1) incorrect (Re) ... times(3) strange; clock_t == long

Craig Groeschel (craig@metrolink.com)
Thu, 29 Feb 1996 09:43:42 -0500 (EST)

> I replayed this time(1) story 2.5 months later, on my BLADE_0.3 platform.
> I think it is [was] due to times(3) which uses [used] to return a

No, I don't think it was the units. I think it was...

> I have also a question on clock_t: it's a `long' on BLADE_0.3 (<asm/types.h>)
> but an `int' on Digital Unix (<sys/types.h>). While perhaps sometimes

If you were to compile time(1) with "gcc -Wall" you would observe some
warnings about printf int/long mismatches. Fixing those up in the time
program made it return proper numbers.

Speaking of the Byte benchmarks, I fixed the "write an long, read an int"
problem in the pipe-based context switch test and sent diffs to the
maintainer of the Linux Benchmark page. The response I got was

> The code doesn't require a patch, BTW. Thousands have ran the code.

Oh well. My mistake I'm sure.

-- 
Craig E. Groeschel  <craig@metrolink.com>  Not speaking for my employer.
"Do not play this piece fast.  It is never right to play Ragtime fast." Joplin
linux$ /bin/pwd: can't load library '/lib/libc.2.2.2'



Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices