struct stat - Unix

This is a discussion on struct stat - Unix ; Gordon Burditt wrote: > [...] > I'd prefer that timestamps go directly to 256 bits (with at least > 64 bits for fractions of a second). That, however, breaks POSIX > requirements for timestamps in units of a second. Sixty-four ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: struct stat

  1. Re: struct stat

    Gordon Burditt wrote:
    > [...]
    > I'd prefer that timestamps go directly to 256 bits (with at least
    > 64 bits for fractions of a second). That, however, breaks POSIX
    > requirements for timestamps in units of a second.


    Sixty-four fraction bits? Whatever for? The low-order bit
    would correspond to the amount of time a photon takes to get not
    quite one twentieth of the way past a hydrogen atom.

    One hundred ninety-two integer bits? Whatever for? The
    high-order bit would correspond to seven duodecillion (7E39)
    times the current estimated age of the Universe.

    What is it you plan to measure, Gordon? Sounds like a big-
    budget project ... ;-)

    --
    Eric.Sosman@sun.com

  2. Re: struct stat

    >> I'd prefer that timestamps go directly to 256 bits (with at least
    >> 64 bits for fractions of a second). That, however, breaks POSIX
    >> requirements for timestamps in units of a second.

    >
    > Sixty-four fraction bits? Whatever for? The low-order bit
    >would correspond to the amount of time a photon takes to get not
    >quite one twentieth of the way past a hydrogen atom.


    Oh. Then we need more fraction bits. I probably need times to
    cover a photon getting one twentieth of the way past a proton or
    an electron.

    The time standard on computers really, really sucks for doing
    subatomic physics calculations. Intervals of seconds doesn't even
    cut it for tracking baseballs pitched or hit by professionals.

    > One hundred ninety-two integer bits? Whatever for? The
    >high-order bit would correspond to seven duodecillion (7E39)
    >times the current estimated age of the Universe.


    Then we really won't have to worry about our very distant ancestors,
    whatever species they may have evolved into, cursing us for our
    shortsightedness. ANSI C did nothing about the Y10K problem.

    > What is it you plan to measure, Gordon? Sounds like a big-
    >budget project ... ;-)


    I'm trying to teleport Schrodinger's cat halfway across the universe.
    Remember those rumors about teleportation at Hewlett-Packard? If
    they can teleport a cat, they can make a really, really long-range
    inkjet printer.


  3. Re: struct stat

    gordonb.r9vn2@burditt.org (Gordon Burditt) writes:
    >>> I'd prefer that timestamps go directly to 256 bits (with at least
    >>> 64 bits for fractions of a second). That, however, breaks POSIX
    >>> requirements for timestamps in units of a second.

    >>
    >> Sixty-four fraction bits? Whatever for? The low-order bit
    >>would correspond to the amount of time a photon takes to get not
    >>quite one twentieth of the way past a hydrogen atom.

    >
    > Oh. Then we need more fraction bits. I probably need times to
    > cover a photon getting one twentieth of the way past a proton or
    > an electron.
    >
    > The time standard on computers really, really sucks for doing
    > subatomic physics calculations. Intervals of seconds doesn't even
    > cut it for tracking baseballs pitched or hit by professionals.


    The time standards for 'subatomic physics calculations' really, really
    sucks even when measureing RTTs in a 'modern' ethernet.

  4. [OT] Re: struct stat

    Gordon Burditt wrote:
    >
    > I'm trying to teleport Schrodinger's cat halfway across the universe.
    > Remember those rumors about teleportation at Hewlett-Packard? If
    > they can teleport a cat, they can make a really, really long-range
    > inkjet printer.


    Be careful! Some of those low-price aftermarket
    cartridges are filled with antimatter ink ...

    --
    Eric Sosman
    esosman@ieee-dot-org.invalid

  5. Re: struct stat

    Gordon Burditt wrote:

    > I'd prefer that timestamps go directly to 256 bits (with at least
    > 64 bits for fractions of a second). That, however, breaks POSIX
    > requirements for timestamps in units of a second.


    The POSIX requirements are changing. The 2008 standard (which has
    been approved by The Open Group and IEEE but not yet published)
    specifies that struct stat contains the following members:

    struct timespec st_atim
    struct timespec st_mtim
    struct timespec st_ctim

    with macros for backward compatibility:
    #define st_atime st_atim.tv_sec
    #define st_mtime st_mtim.tv_sec
    #define st_ctime st_ctim.tv_sec

    and specifies [f]pathconf() with _PC_TIMESTAMP_RESOLUTION to query
    file timestamp resolution (in nanoseconds - maximum allowed value
    1,000,000,000).

    --
    Geoff Clare

  6. Re: struct stat

    On Oct 31, 3:34 pm, Geoff Clare
    wrote:
    > Gordon Burditt wrote:
    > > I'd prefer that timestamps go directly to 256 bits (with at least
    > > 64 bits for fractions of a second). That, however, breaks POSIX
    > > requirements for timestamps in units of a second.

    >
    > The POSIX requirements are changing. The 2008 standard (which has
    > been approved by The Open Group and IEEE but not yet published)
    > specifies that struct stat contains the following members:
    >
    > struct timespec st_atim
    > struct timespec st_mtim
    > struct timespec st_ctim
    >
    > with macros for backward compatibility:
    > #define st_atime st_atim.tv_sec
    > #define st_mtime st_mtim.tv_sec
    > #define st_ctime st_ctim.tv_sec
    >
    > and specifies [f]pathconf() with _PC_TIMESTAMP_RESOLUTION to query
    > file timestamp resolution (in nanoseconds - maximum allowed value
    > 1,000,000,000).


    Is that "standard" available anywhere?

  7. Re: struct stat

    On Oct 31, 12:50*pm, vipps...@gmail.com wrote:
    > On Oct 31, 3:34 pm, Geoff Clare
    > wrote:


    > > Gordon Burditt wrote:


    > > The POSIX requirements are changing. *The 2008 standard (which has
    > > been approved by The Open Group and IEEE but not yet published)
    > > specifies that struct stat contains the following members:

    >
    > > struct timespec st_atim
    > > struct timespec st_mtim
    > > struct timespec st_ctim

    >
    > > with macros for backward compatibility:
    > > #define st_atime st_atim.tv_sec
    > > #define st_mtime st_mtim.tv_sec
    > > #define st_ctime st_ctim.tv_sec

    >
    > > and specifies [f]pathconf() with _PC_TIMESTAMP_RESOLUTION to query
    > > file timestamp resolution (in nanoseconds - maximum allowed value
    > > 1,000,000,000).

    >
    > Is that "standard" available anywhere?


    https://www.opengroup.org/austin/aar...n/xbdfgbug.txt

    DS

  8. Re: struct stat

    On Oct 31, 10:12 pm, David Schwartz wrote:
    > On Oct 31, 12:50 pm, vipps...@gmail.com wrote:
    >
    > > Gordon Burditt wrote:
    > > The POSIX requirements are changing. The 2008 standard (which has
    > > been approved by The Open Group and IEEE but not yet published)
    > > specifies that struct stat contains the following members:

    >
    > > Is that "standard" available anywhere?

    >
    > https://www.opengroup.org/austin/aar...n/xbdfgbug.txt


    Thanks! I didn't know there'd be a 2008 standard. :-)

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2