function for clockticks since 1980?

[nsa.usa]

Hi,

I used to use a function in other languages (TP or asm don't remember)
where I could get number of clockticks since 1980. Is there a similar
function in C? I don't seem to find it.
I need to seed the random generator and since it's a web-server app, I
can't seed with the date/time because the resolution is not great
enough. If the app runs twice in the same second (or millisecond or
whatever the resolution is) then the random generator will be seeded
with the same value! not good. Also don't want to use clockticks
processor has used so far to run the program. It seems to me this
function of ticks since 1980 is what I need, or another guranteed
incremental value.

Thanks.
Tobias

 

[swengineer001]

Hi,

I used to use a function in other languages (TP or asm don't remember)
where I could get number of clockticks since 1980. Is there a similar
function in C? I don't seem to find it.
I need to seed the random generator and since it's a web-server app, I
can't seed with the date/time because the resolution is not great
enough. If the app runs twice in the same second (or millisecond or
whatever the resolution is) then the random generator will be seeded
with the same value! not good. Also don't want to use clockticks
processor has used so far to run the program. It seems to me this
function of ticks since 1980 is what I need, or another guranteed
incremental value.

Thanks.
Tobias

Why not use the IP address?

 

[nsa.usa]

Why not use the IP address?

of the user? the ip can be NATed and also it would be too easy to
guess so would be security risk. I need the random seed to generate
unique session ids.... so everytime the program runs it *must* use a
different random seed..

Cheers,
Tobias

 

[Xu Weijiang]

of the user? the ip can be NATed and also it would be too easy to
guess so would be security risk. I need the random seed to generate
unique session ids.... so everytime the program runs it *must* use a
different random seed..

You can use "CryptGenRandom" in WIN32 systems, and "/dev/random" in
Linux.

Best regards
Xu Weijiang

 

[Ben Bacarisse]

Hi,

I used to use a function in other languages (TP or asm don't remember)
where I could get number of clockticks since 1980. Is there a similar
function in C? I don't seem to find it.
I need to seed the random generator and since it's a web-server app, I
can't seed with the date/time because the resolution is not great
enough. If the app runs twice in the same second (or millisecond or
whatever the resolution is) then the random generator will be seeded
with the same value! not good. Also don't want to use clockticks
processor has used so far to run the program. It seems to me this
function of ticks since 1980 is what I need, or another guranteed
incremental value.

The only function that comes close in standard C is 'time' about which
the standard says:

#include <time.h>
time_t time(time_t *timer);

The time function determines the current calendar time. The
encoding of the value is unspecified.

so you can't rely on much variability there (it *may* be fine, but the
solution would not be portable).

Since there is not ideal portable solution, your best bet may well be
to accept that go fully platform dependent. A small 'get_random_seed'
function will be a couple of lines long and can be written easily for
(reasonable) platform on which a web application might run. Post in a
newsgroup for your which every platform you are currently using for
ideas about getting a good random seed.

 

[nsa.usa]

#include <time.h>
time_t time(time_t *timer);

The time function determines the current calendar time. The
encoding of the value is unspecified.

so you can't rely on much variability there (it *may* be fine, but the
solution would not be portable).

Yeah, this one seems to be down to the second only, and so when the
app is run 100 times (or even just 2 times) within the same second,
then I got a prob =

Since there is not ideal portable solution, your best bet may well be
to accept that go fully platform dependent. A small 'get_random_seed'
function will be a couple of lines long and can be written easily for
(reasonable) platform on which a web application might run. Post in a
newsgroup for your which every platform you are currently using for
ideas about getting a good random seed.

I might try the /dev/random for linux platform as was suggested by Xu
earlier. Just worried about the overhead on that one though. App is
only planned to run on linux on i32 or platform, so I only need it to
work on this (for now..). Im pretty sure there is an interrupt to give
this amount of milliseconds since 1980 on that cpu, but then again I'd
hate to stick in cpu specific stuff..
Somehow I thought this function would be standard in C (I'm not so
used to C)... oh well
Thanks.

Tobias

 

[nsa.usa]

You can use "CryptGenRandom" in WIN32 systems, and "/dev/random" in
Linux.

Best regards
Xu Weijiang

Hi,
Thanks, thats a good idea, I wasn't thinking about that possibillity.
Do you have any idea how to get that value under linux? (I'm not so
used to C), do I just read from the file x bytes or?
Cheers,
Tobias

 

[Ben Pfaff]

The only function that comes close in standard C is 'time' about which
the standard says:

#include <time.h>
time_t time(time_t *timer);

The time function determines the current calendar time. The
encoding of the value is unspecified.

so you can't rely on much variability there (it *may* be fine, but the
solution would not be portable).

One solution is to hash the return value, e.g.

#include <limits.h>
#include <stdlib.h>
#include <time.h>

/* Choose and return an initial random seed based on the current time.
Based on code by Lawrence Kirby <[email protected]>.
Usage: srand (time_seed ()); */
unsigned
time_seed (void)
{
time_t timeval; /* Current time. */
unsigned char *ptr; /* Type punned pointed into timeval. */
unsigned seed; /* Generated seed. */
size_t i;

timeval = time (NULL);
ptr = (unsigned char *) &timeval;

seed = 0;
for (i = 0; i < sizeof timeval; i++)
seed = seed * (UCHAR_MAX + 2u) + ptr;

return seed;
}

 

[Ben Bacarisse]

Yeah, this one seems to be down to the second only, and so when the
app is run 100 times (or even just 2 times) within the same second,
then I got a prob =

The "down to a second only" is on your implementation. A finer
resolution is not prohibited by the standard (nor are tricks such as
having an embedded counter). It would be hard to have a courser
resolution than one second and still keep to the spirit of the other
time functions in the library, but a finer one is possible.

Unfortunately, POSIX has traditionally stated a "seconds since..."
definition for time() (bear with me, this *is* headed on-topic) and
that has meant that doing so kills two standards with one function, so
it seems to have stuck for C as well. I notice, however, that

http://www.opengroup.org/onlinepubs/009695399/ says:

The functionality described on this reference page is aligned with
the ISO C standard. Any conflict between the requirements
described here and the ISO C standard is unintentional. This
volume of IEEE Std 1003.1-2001 defers to the ISO C standard.

The time() function shall return the value of time in seconds since
the Epoch.

A further footnote says:

[where] a statement to the effect that "any conflict is
unintentional" is included. That is intended to refer to a direct
conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO
C standard, and it may choose to further constrain behaviors allowed
to vary by the ISO C standard. Such limitations are not considered
conflicts.

This let-out seems a shame in this case. Further constraining the
behaviour to seconds since X seems to me to be a serious conflict and
limits what existing C libraries can do (unless they provide a POSIX-
compatible alternative). An implementation that chose to make time_t
big in readiness for 2038 could have thrown in some extra bits at the
bottom for more precision (even if all they did was count 'time'
calls).

Anyway, to the OP: you know the score -- use something non-portable
from Solaris, Linux, HP-UX, whatever target is [but do read on in case
I guessed wrong...]

I might try the /dev/random for linux platform as was suggested by Xu
earlier. Just worried about the overhead on that one though.

<OT>It is slow to open+read+close, but fast if you just read it (I
get a ratio of 1000 to 1!) so if you need multiple seeds per run, open
it once.<OT>

Interesting, if your application is long-running -- i.e. the program
runs and issues many session ids -- then you *do* have a solution in
portable C:

static counter = 0;
session_id = some_hash_of(combine(time(NULL), ++counter));
/* combine(t, c) can just return t + c; */

but I had assumed this was a "runs once per connection", CGI type,
application.

[BTW, don't quote sigs!]

 

[Ben Bacarisse]

(e-mail address removed) writes:

Make that dev/urandom. Another reason I suggested you post in a
"platform" group. A horde of posters on would have steered you to urandom and away from random for all but the
most cryptographically sensitive applications.

 

[Ben Bacarisse]

One solution is to hash the return value, e.g.

You don't get any more variability that way (at least in the sense
that matters to the OP). Two identical times give identical hashed
times.

 

[Peter J. Holzer]

Yeah, this one seems to be down to the second only, and so when the
app is run 100 times (or even just 2 times) within the same second,
then I got a prob =


I might try the /dev/random for linux platform as was suggested by Xu
earlier.

/dev/random is guarantueed to return random numbers - if there is not
enough entropy in the pool it will block until more entropy is
collected. On a busy web server you will probably rapidly running out of
entropy, and you probably don't need that level of randomness, so you
should use /dev/urandom instead.

Just worried about the overhead on that one though. App is
only planned to run on linux on i32 or platform, so I only need it to
work on this (for now..).

Linux and other POSIX-compatible systems have the gettimeofday function,
which returns the time in seconds and microseconds since the epoch. Be
warned that the actual resolution of the clock can be much coarser:
Linux/x86 actually uses a microsecond clock, but some other Unixes have
resolutions of something between 1/60 to 1/1024 of a second.

Im pretty sure there is an interrupt to give this amount of
milliseconds since 1980 on that cpu, but then again I'd hate to stick
in cpu specific stuff..

These things are rarely CPU-specific. They are, however, OS-specific and
in some cases system specific. (BTW, the epoch on POSIX systems is 1970,
not 1980)

Somehow I thought this function would be standard in C (I'm not so
used to C)... oh well

The C standard specifies a baseline which all implementations must
conform to. It is therefore very conservative and doesn't mandate
functions which might be impossible to implement on some systems (e.g.,
not every system has a clock with millisecond resolution). You will
notice that the standard doesn't make any guarantuees about the
resolution of time_t: It may have a resolution of nanoseconds, or only
of minutes.

hp

 

[Peter J. Holzer]

Unfortunately, POSIX has traditionally stated a "seconds since..."
definition for time() (bear with me, this *is* headed on-topic) and
that has meant that doing so kills two standards with one function, so
it seems to have stuck for C as well. I notice, however, that

http://www.opengroup.org/onlinepubs/009695399/ says:

The functionality described on this reference page is aligned with
the ISO C standard. Any conflict between the requirements
described here and the ISO C standard is unintentional. This
volume of IEEE Std 1003.1-2001 defers to the ISO C standard.

The time() function shall return the value of time in seconds since
the Epoch.

A further footnote says:

[where] a statement to the effect that "any conflict is
unintentional" is included. That is intended to refer to a direct
conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO
C standard, and it may choose to further constrain behaviors allowed
to vary by the ISO C standard. Such limitations are not considered
conflicts.

This let-out seems a shame in this case. Further constraining the
behaviour to seconds since X seems to me to be a serious conflict

I don't think so. The C standard only guarantees that time_t is an
arithmetic type capable of representing times. It doesn't make any
further requirements. An integral type counting seconds since 1970
certainly meets this requirement, so each system conforming to the POSIX
standard is also conforming to the C standard.

BTW, while I am quite sure that earlier versions of the POSIX standard
restricted time_t to an integral type,
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
doesn't:

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

So it is perfectly ok for time() to return 1185708188.123456 to
represent a time 123456 microseconds ater 2007-07-29 11:23:08 UTC.

and limits what existing C libraries can do

Yes. That's the point. POSIX-conforming systems are a subset of
C-conforming systems. They make more guarantuees and are therefore more
limited. A standard which includes ISO-9899 can never relax requirements
of ISO-9899, it can only add additional requirements.

An implementation that chose to make time_t big in readiness for 2038
could have thrown in some extra bits at the bottom for more precision
(even if all they did was count 'time' calls).

It can still do that, but only if it switches to floating-point (which I
think would be the sane thing to do, once 2038 approaches).

hp

 

[Xu Weijiang]

Hi,
Thanks, thats a good idea, I wasn't thinking about that possibillity.
Do you have any idea how to get that value under linux? (I'm not so
used to C), do I just read from the file x bytes or?

Yes, in Linux, a device is only a special file.

Here is a small example (need to include <unistd.h>):

//-------
int rand_fd;
rand_fd = open ("/dev/random", O_RDONLY);
read (rand_fd, &bytes, 4);
close (rand_fd);
//-------

Be ware it is unportable,

Best regards
Xu Weijiang

 

[Ben Bacarisse]

Unfortunately, POSIX has traditionally stated a "seconds since..."
definition for time() (bear with me, this *is* headed on-topic) and
that has meant that doing so kills two standards with one function, so
it seems to have stuck for C as well. I notice, however, that

http://www.opengroup.org/onlinepubs/009695399/ says:

The functionality described on this reference page is aligned with
the ISO C standard. Any conflict between the requirements
described here and the ISO C standard is unintentional. This
volume of IEEE Std 1003.1-2001 defers to the ISO C standard.

The time() function shall return the value of time in seconds since
the Epoch.

A further footnote says:

[where] a statement to the effect that "any conflict is
unintentional" is included. That is intended to refer to a direct
conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO
C standard, and it may choose to further constrain behaviors allowed
to vary by the ISO C standard. Such limitations are not considered
conflicts.

This let-out seems a shame in this case. Further constraining the
behaviour to seconds since X seems to me to be a serious conflict

I don't think so. The C standard only guarantees that time_t is an
arithmetic type capable of representing times. It doesn't make any
further requirements. An integral type counting seconds since 1970
certainly meets this requirement, so each system conforming to the POSIX
standard is also conforming to the C standard.

Yes, I got that. Extra restrictions are not considered conflicts.
I think that is a shame because it means that some conforming C
libraries would at odds with POSIX.

Yes. That's the point.

And it was my only point! It just seems like a missed opportunity.
Had POSIX said: "time() will be exactly as in ISO C, no more, no less"
and then went on to mandate, say:

time_t time_to_sec_since_1970(time_t t);

(which would be a no-op macro on many systems) then they would have
been decoupled from what C implementers do now, and from what ISO C
might do in the future (provided C keeps time_t as some time that can be
converted as above).

 

[CBFalconer]

.... snip ...

Here is a small example (need to include <unistd.h>):

//-------
int rand_fd;
rand_fd = open ("/dev/random", O_RDONLY);
read (rand_fd, &bytes, 4);
close (rand_fd);
//-------

No such things as unistd.h, open, read, close in standard C. This
makes this entirely off-topic in this newsgroup.

 

[Keith Thompson]

BTW, while I am quite sure that earlier versions of the POSIX standard
restricted time_t to an integral type,
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
doesn't:

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

So it is perfectly ok for time() to return 1185708188.123456 to
represent a time 123456 microseconds ater 2007-07-29 11:23:08 UTC.

Yes, in both C and POSIX. But the use of floating-point for time_t
would introduce some problems. The precision would vary considerably
over time, and some of the bits would be wasted on the ability of
representing times *extremely* close to the epoch. I prefer a uniform
precision over the entire representable range.

[...]

It can still do that, but only if it switches to floating-point (which I
think would be the sane thing to do, once 2038 approaches).

I disagree. Assuming an integer representation that overflows in
2038, it's far more sensible IMHO to move to 64 bits (signed). Many
implementations have already done so, and I see no reason that *all*
implementations can't do so in the next 30 years.

[...]

 

[Keith Thompson]

Yes, I got that. Extra restrictions are not considered conflicts.
I think that is a shame because it means that some conforming C
libraries would at odds with POSIX.

Right. I don't think it was ever the intent that all conforming C
libraries must conform to POSIX.

POSIX is a big standard, and the time interface is only a small part
of it. I seriously doubt that there are any libraries that conform to
POSIX *except* for the representation of time_t.

And it was my only point! It just seems like a missed opportunity.
Had POSIX said: "time() will be exactly as in ISO C, no more, no less"
and then went on to mandate, say:

time_t time_to_sec_since_1970(time_t t);

(which would be a no-op macro on many systems) then they would have
been decoupled from what C implementers do now, and from what ISO C
might do in the future (provided C keeps time_t as some time that can be
converted as above).

If the time representation were a real concern (I don't think it is),
then something like the above could be a good way to deal with it.
But the time_to_sec_since_1970 function should probably return
something other than time_t, since the underlying C library's
implementation of time_t might not be suitable for representing
seconds since 1970. Using the same time to represent seconds since
1970 and, say, weeks since 1900 would cause confusion, especially for
the inevitable sloppily written programs that don't bother to call
time_to_sec_since_1970 because "it works fine on my system".

 

[Peter J. Holzer]

Unfortunately, POSIX has traditionally stated a "seconds since..."
definition for time() (bear with me, this *is* headed on-topic) and
that has meant that doing so kills two standards with one function, so
it seems to have stuck for C as well. I notice, however, that [...]
[where] a statement to the effect that "any conflict is
unintentional" is included. That is intended to refer to a direct
conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO
C standard, and it may choose to further constrain behaviors allowed
to vary by the ISO C standard. Such limitations are not considered
conflicts.

This let-out seems a shame in this case. Further constraining the
behaviour to seconds since X seems to me to be a serious conflict

I don't think so. The C standard only guarantees that time_t is an
arithmetic type capable of representing times. It doesn't make any
further requirements. An integral type counting seconds since 1970
certainly meets this requirement, so each system conforming to the POSIX
standard is also conforming to the C standard.

Yes, I got that. Extra restrictions are not considered conflicts.
I think that is a shame because it means that some conforming C
libraries would at odds with POSIX.

Yes. Just like POSIX puts extra restrictions/guarantees on file I/O and
other areas.

And it was my only point! It just seems like a missed opportunity.

Apparently they considered standardizing the relationship between the
value of a time_t and UTC important. I agree with that. Having a
standard, portable timestamp format is very handy. POSIX and ANSI-C were
created at about the same time (POSIX in 1988, ANSI-C in 1989). I
suppose at the time the time() function returned seconds since 1970 on
all unixish systems, but other values on some non-unixish systems - so
POSIX could standardize it while ANSI-C could not. (So I see it the
other way round: ANSI-C missed the opportunity to standardize time_t)

And note that POSIX only standardized the value, but not the type: A
POSIX system is still free to use a floating point type to represent
fractional seconds. There are a few things which a POSIX time_t cannot
encode, but a C time_t can: Leap seconds and time zones, for example.
Both would be more trouble than they are worth, IMHO.

Had POSIX said: "time() will be exactly as in ISO C, no more, no less"
and then went on to mandate, say:

time_t time_to_sec_since_1970(time_t t);

That would be a bad idea. Then time_t can be two very different things.
That would have to be

seconds_since_1970_t time_to_sec_since_1970(time_t t);

or something like that. (That could be done easily with difftime if
the time_t value of 1970-01-01T00:00:00+0000 could be computed. But the
standard doesn't guarantuee that that date is even representable in a
time_t, or that the local timezone is determinable).

hp

 

[Walter Roberson]

I used to use a function in other languages (TP or asm don't remember)
where I could get number of clockticks since 1980. Is there a similar
function in C? I don't seem to find it.

Presuming that you will want to run the code for another couple of
years, that would require at least a 57 bit number, if one's
baseline is a 3 GHz clock. (Posters down-thread talking about
making time_t a floating type: note that IEEE 754 64 bit double
precision numbers lack enough accuracy for the OP's requested resolution.)

I need to seed the random generator and since it's a web-server app, I
can't seed with the date/time because the resolution is not great
enough. If the app runs twice in the same second (or millisecond or
whatever the resolution is) then the random generator will be seeded
with the same value! not good.

You don't need clock-ticks since 1980, not unless you are planning
to run retroactive transactions for 25 years ago. You only need
(at best) clock-ticks since some arbitrary reference point
starting about now.

Several people have suggested using /dev/random or /dev/urandom in Linux.
However, the nature of random number generators and pseudo-
random number generators is that you get repeated values (or at least
you do on the better ones) -- "uniformly distributed random numbers"
are, mathematically, "selection with replacement", and if you can
never generate the same numbers, you have "selection without
replacement" which is not "uniformly distributed". If you use a
pseudo random-number generator, then you need to keep careful track
of the "seed" that is currently in use, because if you have a crash
(or power outage, or maintenance, or switch to a new machine) then you
need to pick up with exactly the same internal seed you left off at --
if you don't, then you risk accidently re-using random numbers and
thus session-IDs. Unless, that is, one of your components in creating
the session ID is an absolute timestamp at a resolution fine enough
as to be sure to have a different value when your system came back up.
But if you don't have that, if you do need to keep complete track
of the current PRNG seed, then you might as well just use a sequential
counter (and hash the constructed session ID together with some
private key.)