Getting nanoseconds in a process

[Ian Collins]

The word 'timespec' does not appear in the C standard. Thus no
such thing exists in the standard C language, and intimating that
it does is a pure falsity.

Ho hum, late to the party again...

 

[Nate Eldredge]

Anthony Fremont wrote:

/* Print out the results */
for (index = 0; index < SIZE; index++) {
printf("[%d]: %d.%d\n", index,
(int) timevals[index].tv_sec,
(int) timevals[index].tv_usec);

Again, why cast?

To eliminate the warnings.

Then use the correct conversion specification.

The types of the `tv_sec' and `tv_usec' members of `struct
timeval' are`time_t' and `suseconds_t' respectively. What
conversion specifiers do you recommend?

%ld.

I see no specification for time_t, other than arithmetic type, so
that conversion is probably accurate. However, there is no
specification whatsoever for suseconds_t.

The documentation for the Unix gettimeofday function says that it is a
signed integer type capable of representing the range [-1,1000000], and
the tv_usec member returned from gettimeofday will have a value in that
range. Given which, a cast to `long int' should be good enough. (Just
using %ld isn't enough, though, because suseconds_t could also be a type
smaller than `long int'.)

 

[Nate Eldredge]

Fair enough, I was cheating by looking at my system's headers. Casting
to the system's largest int type should be safe enough.

Not quite; time_t could be a floating point type, and a value returned
from time() could easily be larger than will fit in the system's largest
int type.

Conversely, time_t could be an integer type that doesn't fit in the
system's largest floating point type (unlikely but allowed), so casting
to `long double' or the like isn't safe either.

 

[Ian Collins]

Not quite; time_t could be a floating point type, and a value returned
from time() could easily be larger than will fit in the system's largest
int type.

Like many of these vaguely defined standard types, the Single Unix
Specification tightens them: "size_t is an unsigned integral type".

 

[Keith Thompson]

Fair enough, I was cheating by looking at my system's headers. Casting
to the system's largest int type should be safe enough.

[...]

For certain values of "enough". It's certainly theoretically possible
for time_t to be a floating-point type, and for a value to exceed
UINT_MAX_MAX.

 

[Ben Bacarisse]

Like many of these vaguely defined standard types, the Single Unix
Specification tightens them: "size_t is an unsigned integral type".

That is what the C standard says (with some extras). About time_t,
SUS does say a bit more, but not enough to help here:

* time_t and clock_t shall be integer or real-floating types.

 

[Nate Eldredge]

Complex types are arithmetic types. Conceivably, an implementation
could use both components of a complex type for its time_t
representation.

Ooh, good point. That would be brilliantly perverse.

You'd have to dick around with cimag*() and creal*().

Not really worth it, in my opinion. As you say elsewhere, leave it
to the appropriate functions to mess with time_t values.

Indeed.

 

[Keith Thompson]

Nate Eldredge wrote: [...]

Not quite; time_t could be a floating point type, and a value returned
from time() could easily be larger than will fit in the system's largest
int type.

Like many of these vaguely defined standard types, the Single Unix
Specification tightens them: "size_t is an unsigned integral type".

size_t

time_t

One of these is not like the other.

 

[CBFalconer]

.... snip ...

I see no specification for time_t, other than arithmetic type,
so that conversion is probably accurate. However, there is no
specification whatsoever for suseconds_t.

The documentation for the Unix gettimeofday function says that
it is a signed integer type capable of representing the range
[-1,1000000], and the tv_usec member returned from gettimeofday
will have a value in that range. Given which, a cast to `long
int' should be good enough. (Just using %ld isn't enough,
though, because suseconds_t could also be a type smaller than
`long int'.)

While I assume you are quite correct for Unix, that discussion
belongs on comp.unix.programmer, not here.

 

[Nelu]

Hi there!

Here's how to display the values:

------------------------------------------------------------------------
#include <stdio.h>
#include <time.h>

int main(void)
{
time_t t;
struct tm *tp;
char tstr[256];

t = time(NULL);

t may be (time_t)(-1) if it can't return the time.

tp = localtime(&t);

t may be NULL if localtime cannot convert to local time.

/* returns 0 if output won't fit in tstr - in which case,
don't assume anything about the contents of tstr. */
strftime(tstr, sizeof tstr,
"Day: %d\n"
"Hour: %H\n"
"Minute: %M\n"
"Second: %S\n", tp);

It's going to be interesting when tp-><something> is checked when tp is
NULL. Oh, no... Segmentation fault.

t = time(NULL);
tp = localtime(&t);

Again, a small problem with NULL.

The above are strictly conforming C programs.

However, you should add some safeguards.

Now for the %N case.

You're on Ubuntu Linux, presumably.

Can you say that for sure? If yes, what makes you think that (for sure)?

The date(1) command on your system
is from GNU coreutils. GNU date(1) has a %N extension for nanoseconds
that is implemented by, in order of preference:

nanotime()

Can't find it in the manpages.

clock_gettime(CLOCK_REALTIME, ...)
gettimeofday() with crappy resolution

Those three functions are on-topic here (see my topicality guidelines
below), so if you pick one, I'll teach you how to use it.

Hopefully, you know more about these than about the functions in

Good luck with your C programming

Yep... he'll need it.

Whether this newsgroup is strictly for ANSI/ISO C is a matter of opinion,
since this newsgroup has no charter and, in fact, has a founding message
that predates ANSI/ISO C. The spirit of the founding message was that this
newsgroup would be for discussions of C and anything tangential to C.
Nobody who has come along so far has any right to rewrite the founding
message and impose an ANSI/ISO C topicality restriction on this newsgroup,
whether by informal echo-chamber vote of a few dozen "regulars" or not.

"any right"? You can't handle "any right".

As long as your posts are about C or matters tangential to C, plenty of
people here will be happy to assist you. To get the most coverage for your
questions, however, you have the option of cross-posting to all relevant
newsgroups, including this one. That way, you have more experts available
to contribute answers.

Yes, but not everyone knows the relevant newsgroups so it's your duty to
point them out before giving bad advice with no one to call you out on it.

When deciding whom to listen to, take into account who helps you and who
doesn't. It's pretty hard to ignore someone who's giving you the help you
seek.

Yes, get into cars with strangers that give you candy.

<snip Han's self description>
kick you off to another newsgroup.

ref1 ^^^

They may say
something about the experts being able to correct one another's posts over
there, but that's a poor argument for at least two reasons: (1) As I said
above, you have the option of cross-posting to all relevant newsgroups,
including this one;

This is worst than the first one... because this time you actually shut
off any chance of redirection by your own rules (see ref1).

(2) It's been demonstrated multiple times on this
newsgroup that the experts are unlikely to correct one another's posts if
they happen to like one another. At least with multiple newsgroups there's
less chance of this happening, as can be seen in the healthy kinds of
debate that occur when threads cross newsgroup boundaries.
Killfiled?


A number of "established topicality" contradictions have been exposed, and
these contradictions have yet to be addressed. Every time these
contradictions have been raised, the topicality monitors suddenly go very
quiet. Why is that do you think? What does your gut tell you?

Maybe they *really* killfiled you?

The topicality monitors would better be served by creating comp.lang.c.iso
or comp.lang.iso-c and seeing how popular that becomes.

Wait, what? Why don't you do that? Call it net.lang.c.
This is not about topicality, this is about getting along and about
offering correct information and you don't seem to be particularly good
at neither. That's fine, we all make mistakes, but not all of us do
things just to spite others.

 

[Nelu]

Nate Eldredge wrote:

%ld.

The implementation defines the precision of time_t so I'm not sure %ld
is correct. I think time_t is one of those wacky types that you're not
supposed to be using for anything meaningful in portable code.

 

[Nelu]

I think you just complemented Han. Was that your intention? Or was there a typo?

What do you mean?

 

[Nelu]

Nelu said:


It was a spelling flame (or possibly a typing flame). He was
criticising your "neither", which ought to have been "either".

Thanks. I'm still having some issues mastering either and neither. Is it
"either" because of the "don't"?

 

[Nate Eldredge]

... snip ...

I see no specification for time_t, other than arithmetic type,
so that conversion is probably accurate. However, there is no
specification whatsoever for suseconds_t.

The documentation for the Unix gettimeofday function says that
it is a signed integer type capable of representing the range
[-1,1000000], and the tv_usec member returned from gettimeofday
will have a value in that range. Given which, a cast to `long
int' should be good enough. (Just using %ld isn't enough,
though, because suseconds_t could also be a type smaller than
`long int'.)

While I assume you are quite correct for Unix, that discussion
belongs on comp.unix.programmer, not here.

There's a C question underlying it, though.

"If foo is a type, supplied by some library, which is known only to be a
signed integer capable representing the range [-1,1000000], how can we
print out a value of type foo, in a manner that will continue to work if
another version of the library should change foo to a different type
with the same property?"

Now replace foo with suseconds_t.

 

[Keith Thompson]

What do you mean?

You probably meant to write "... and you don't seem to be
particularly good at *either*" rather than "neither". A painfully
literal reading of what you wrote could imply the opposite of what
you intended. I don't think it was a serious comment, though;
nobody intending a compliment would have phrased it that way.

 

[Richard]

Thanks. I'm still having some issues mastering either and neither. Is it
"either" because of the "don't"?

No. And neither was it the other nor the last.

 

[Richard]

... snip ...

I see no specification for time_t, other than arithmetic type,
so that conversion is probably accurate. However, there is no
specification whatsoever for suseconds_t.

The documentation for the Unix gettimeofday function says that
it is a signed integer type capable of representing the range
[-1,1000000], and the tv_usec member returned from gettimeofday
will have a value in that range. Given which, a cast to `long
int' should be good enough. (Just using %ld isn't enough,
though, because suseconds_t could also be a type smaller than
`long int'.)

While I assume you are quite correct for Unix, that discussion
belongs on comp.unix.programmer, not here.

There's a C question underlying it, though.

"If foo is a type, supplied by some library, which is known only to be a
signed integer capable representing the range [-1,1000000], how can we
print out a value of type foo, in a manner that will continue to work if
another version of the library should change foo to a different type
with the same property?"

Now replace foo with suseconds_t.

Of course it is - well said.

I watch with wonder how only a short time after proclaiming himself the
champion of group moderation Heathfield and some lackeys are now piling
in trying to scupper a helpful and interesting thread. neither or either
indeed.

 

[Keith Thompson]

... snip ...

I see no specification for time_t, other than arithmetic type,
so that conversion is probably accurate. However, there is no
specification whatsoever for suseconds_t.

The documentation for the Unix gettimeofday function says that
it is a signed integer type capable of representing the range
[-1,1000000], and the tv_usec member returned from gettimeofday
will have a value in that range. Given which, a cast to `long
int' should be good enough. (Just using %ld isn't enough,
though, because suseconds_t could also be a type smaller than
`long int'.)

While I assume you are quite correct for Unix, that discussion
belongs on comp.unix.programmer, not here.

Suppose you have a type defined (in your program, in a library, or
wherever) that's documented to be a signed integer type capable of
representing the range [-1,1000000], and a function that returns a
value of that type in that range. How can you portably print that
value? Answer: cast to long int and use "%ld". That's a perfectly
portable answer to a topical question. The fact that the type happens
to be defined by Unix doesn't make it any less so.

 

[Keith Thompson]

Thanks. I'm still having some issues mastering either and neither. Is it
"either" because of the "don't"?

Right. English (which I'm guessing isn't your native language)
doesn't use double negatives the way some languages do. To negate
the meaning of a sentence, one usually adds a single "not" or
reverses the sense of one word. Both "don't" (a contraction of
"do not") and "neither" (equivalent to "not either") are negatives.
A double negative is usually either considered ungrammatical or,
if one is being painfully literal, the two negatives cancel each
other out (like two "!" operators in C).

(If you're a rock singer, you can get away with things like "I can't
get no satisfaction".)

 

[Nelu]

Right. English (which I'm guessing isn't your native language)
doesn't use double negatives the way some languages do.

Thank you.

I know about the double negatives and about "not either" but I wasn't
sure it applied here.