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]

On Jul 28, 7:52 pm, [e-mail] wrote:

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]

On Jul 29, 1:59 am, "[e-mail]"
<[e-mail]:

On Jul 28, 7:52 pm, [e-mail] wrote:

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?

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]

ns*****@gmail.com writes:

On Jul 29, 1:59 am, "[e-mail]"
<[e-mail]:

>On Jul 28, 7:52 pm, [e-mail] wrote:

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?

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
--
everything has its rules!

[Ben Bacarisse]

ns*****@gmail.com writes:

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.

--
Ben.

[nsa.usa]

On Jul 29, 2:58 am, Ben Bacarisse <[e-mail]:

#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.

--
Ben.

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]

On Jul 29, 2:49 am, Xu Weijiang <[e-mail]:

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

Best regards
Xu Weijiang
--
everything has its rules!

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]

Ben Bacarisse <be********@bsb.me.ukwrites:

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 <fr**@genesis.demon.co.uk>.
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[i];

return seed;
}
--
Ben Pfaff
http://benpfaff.org

[Ben Bacarisse]

ns*****@gmail.com writes:

On Jul 29, 2:58 am, Ben Bacarisse <[e-mail]:

> #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 =:-)

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.

[Ben Bacarisse]

Ben Bacarisse <be********@bsb.me.ukwrites:

ns*****@gmail.com writes:

<big snip>

>I might try the /dev/random for linux platform..

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

--
Ben.

[Ben Bacarisse]

Ben Pfaff <bl*@cs.stanford.eduwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

>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.

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.

--
Ben.

[Peter J. Holzer]

On 2007-07-29 01:16, ns*****@gmail.com <ns*****@gmail.comwrote:

On Jul 29, 2:58 am, Ben Bacarisse <[e-mail]:

> #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.

/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 | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Peter J. Holzer]

On 2007-07-29 04:22, Ben Bacarisse <be********@bsb.me.ukwrote:

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/...s/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
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Xu Weijiang]

ns*****@gmail.com writes:

On Jul 29, 2:49 am, Xu Weijiang <[e-mail]:

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

Best regards
Xu Weijiang
--
everything has its rules!

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
--
everything has its rules!

[Ben Bacarisse]

"Peter J. Holzer" <hj*********@hjp.atwrites:

On 2007-07-29 04:22, Ben Bacarisse <be********@bsb.me.ukwrote:

>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.

>and limits what existing C libraries can do

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).

--
Ben.

[Keith Thompson]

"Peter J. Holzer" <hj*********@hjp.atwrites:
[...]

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/...s/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.

[...]

>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).

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Ben Bacarisse <be********@bsb.me.ukwrites:
[...]

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".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Peter J. Holzer]

On 2007-07-29 13:46, Ben Bacarisse <be********@bsb.me.ukwrote:

"Peter J. Holzer" <hj*********@hjp.atwrites:

>On 2007-07-29 04:22, Ben Bacarisse <be********@bsb.me.ukwrote:

>>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 limits what existing C libraries can do

Yes. That's the point.

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
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Walter Roberson]

In article <11**********************@o61g2000hsh.googlegroups .com>,
<ns*****@gmail.comwrote:

>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.)
--
Prototypes are supertypes of their clones. -- maplesoft

[Peter J. Holzer]

On 2007-07-29 16:17, Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:

In article <11**********************@o61g2000hsh.googlegroups .com>,
<ns*****@gmail.comwrote:

>>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.

I think the OP referred to the real-time clock, not the CPU clock. So
the clock frequency would be at most 1 kHz, not 3 GHz.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Spoon]

Peter J. Holzer wrote:

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.

Linux/x86 (and possibly other platforms as well) are able to offer
sub-jiffie resolution by interpolating cycle counter values.

On Linux/x86 the /resolution/ is less than 1 ns when using the TSC
on a CPU faster than 1 GHz.

(Contrast resolution with precision and accuracy.)

[Keith Thompson]

"Peter J. Holzer" <hj*********@hjp.atwrites:
[...]

gettimeofday returns time in a struct containing to integral values, one
representing seconds, and the other microseconds. So the precision is
1 µs. The resolution (or granularity) may be much coarser, though. Image
an system, which doesn't have a high resolution timer (or doesn't use it
for computing system time), instead it has a timer chip which generates
interrupts at 256 Hz, and a counter is incremented at each interrupt
(this is called "jiffies" in Linux, but just "clock ticks" on most
systems). On such a system, if you call gettimeofday repeatedly, it may
return 11718 in the microseconds field several times, then 15625 several
times, then 19531, etc. All in all, just 256 different values.

[...]

This isn't strictly topical, except that I'm going to argue that it
could theoretically apply to the behavior of the standard time()
function.

I've seen implementations of gettimeofday() whose actual precision is
fairly coarse (say, 0.01 second), but that still manage to yield a
unique value on each call. For example, successive results might be
something like:

{ 1185837859, 730000 }
{ 1185837859, 730001 }
{ 1185837859, 730002 }
{ 1185837859, 730003 }
{ 1185837859, 730004 }
{ 1185837859, 740000 }
{ 1185837859, 740001 }
...

In other words, if gettimeofday() is called again within the same
0.01-second interval, the implementation successively adds one
microsecond to the result to make it unique.

A time() implementation that returns, say, microseconds since some
epoch in 64 bits could do the same thing. But of course it's not
required to do so <OT>nor is gettimeofday()</OT>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Xu Weijiang wrote:

>

.... 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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

[David Thompson]

On Sun, 29 Jul 2007 16:17:37 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:

In article <11**********************@o61g2000hsh.googlegroups .com>,
<ns*****@gmail.comwrote:

<snip>

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

However, it should be extremely unlikely to repeat a value for two
consecutive tries, or even within a window small relative to the
range. And for many _P_RNGs impossible, even though they are indeed
uniform over a large (enough) window. Yes, in principle a (T)RNG could
return a thousand consecutive zeros, but in practice one that does so
is broken, not absurdly lucky.

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.

Or just any value which is (reliably) different when you come back up.
I worked on a system that for database transaction-id's, which
similarly need to be globally and permanently unique (for suitable
definitions of global and permanent), included a "crash count" (in
reserved stable=disk storage) which was incremented on a startup that
did not find clean state stored. (If clean state WAS found, it
included the next value for a, in this case, sequential counter.)

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.)

Assuming the hash does not interact badly with some (any) structure of
the input. The hashes used in (modern = computer) cryptography like
MD5 and SHA1 (to name the most common and best known) are designed to
produce pseudorandom output for any unique input sequence, of which a
counter is the simplest case. Other (homegrown) hashes do not come
with the same kind of "guarantee". (Research fairly recently, about a
year ago, has found _collision_ attacks on MD5, that is where the
adversary can control the input to the hash, or most of it, but so far
as is known, this does not weaken it for the type of usage here.
Modern ciphers like DES and AES are similarly designed to be
pseudorandom _permutations_ hence reversible of their input = output
space, and thus one now-NIST-approved mode of operation is essentially
to encrypt sequential counter values and use the results for a
conventional (XOR) stream cipher -- subject the limitations for all
such stream ciphers regarding known-plain alteration etc.)

- formerly david.thompson1 || achar(64) || worldnet.att.net