function for clockticks since 1980?

Discussion in 'C Programming' started by nsa.usa@gmail.com, Jul 29, 2007.

  1. Guest

    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
    , Jul 29, 2007
    #1
    1. Advertising

  2. Guest

    On Jul 28, 7:52 pm, 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?
    , Jul 29, 2007
    #2
    1. Advertising

  3. Guest

    On Jul 29, 1:59 am, ""
    <> wrote:
    > On Jul 28, 7:52 pm, 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
    , Jul 29, 2007
    #3
  4. Xu Weijiang Guest

    writes:

    > On Jul 29, 1:59 am, ""
    > <> wrote:
    >> On Jul 28, 7:52 pm, 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!
    Xu Weijiang, Jul 29, 2007
    #4
  5. 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.
    Ben Bacarisse, Jul 29, 2007
    #5
  6. Guest

    On Jul 29, 2:58 am, Ben Bacarisse <> wrote:

    > #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
    , Jul 29, 2007
    #6
  7. Guest

    On Jul 29, 2:49 am, Xu Weijiang <> wrote:

    >
    > 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
    , Jul 29, 2007
    #7
  8. Ben Pfaff Guest

    Ben Bacarisse <> writes:

    > 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 <>.
    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 Pfaff
    http://benpfaff.org
    Ben Pfaff, Jul 29, 2007
    #8
  9. writes:

    > On Jul 29, 2:58 am, Ben Bacarisse <> wrote:
    >
    >> #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, Jul 29, 2007
    #9
  10. <OT> correction Was: Re: function for clockticks since 1980?

    Ben Bacarisse <> writes:

    > 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, Jul 29, 2007
    #10
  11. Ben Pfaff <> writes:

    > Ben Bacarisse <> writes:
    >
    >> 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.
    Ben Bacarisse, Jul 29, 2007
    #11
  12. On 2007-07-29 01:16, <> wrote:
    > On Jul 29, 2:58 am, Ben Bacarisse <> wrote:
    >
    >> #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.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Jul 29, 2007
    #12
  13. On 2007-07-29 04:22, Ben Bacarisse <> wrote:
    > 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


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Jul 29, 2007
    #13
  14. Xu Weijiang Guest

    writes:

    > On Jul 29, 2:49 am, Xu Weijiang <> wrote:
    >
    >>
    >> 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!
    Xu Weijiang, Jul 29, 2007
    #14
  15. "Peter J. Holzer" <> writes:

    > On 2007-07-29 04:22, Ben Bacarisse <> wrote:
    >> 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.
    Ben Bacarisse, Jul 29, 2007
    #15
  16. CBFalconer Guest

    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
    CBFalconer, Jul 29, 2007
    #16
  17. "Peter J. Holzer" <> writes:
    [...]
    > 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.

    [...]

    >> 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) <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, Jul 29, 2007
    #17
  18. Ben Bacarisse <> writes:
    [...]
    > 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) <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, Jul 29, 2007
    #18
  19. On 2007-07-29 13:46, Ben Bacarisse <> wrote:
    > "Peter J. Holzer" <> writes:
    >> On 2007-07-29 04:22, Ben Bacarisse <> wrote:
    >>> 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.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Jul 29, 2007
    #19
  20. In article <>,
    <> wrote:

    >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
    Walter Roberson, Jul 29, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vertigo

    days since 1 Jan 1970

    vertigo, Jul 7, 2004, in forum: Perl
    Replies:
    6
    Views:
    7,308
    Joe Smith
    Jul 8, 2004
  2. Herve MAILLARD
    Replies:
    2
    Views:
    513
    John Saunders
    Jul 23, 2003
  3. tdi1686
    Replies:
    2
    Views:
    368
    Kevin Spencer
    Aug 13, 2003
  4. Paul Turley
    Replies:
    1
    Views:
    560
  5. Ralph Corderoy

    Re: 1980's Home Computer-style Package.

    Ralph Corderoy, Jun 16, 2005, in forum: Python
    Replies:
    2
    Views:
    300
    Lee Harr
    Jun 16, 2005
Loading...

Share This Page