N2285, which can be found at

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2285.html#xtime

defines the structure xtime as follows:

typedef struct {
    int sec;    /* seconds since 1 Jan. 1970 00:00:00 */
    int nsec;   /* nanoseconds since time specified by sec */
} xtime;

IMO this specification leads to problematic situation related
to the point, how one can portably define such a structure
with a time value of some milliseconds, which is a rather
mild request for usual hardware.
The range of int is not exactly specified, but taking the C99
standard as reference, we find in 5.2.4.2.1/1 that INT_MAX
must be at least +32767 large. Using such a limiting - but
conforming - implementation, it's impossible

(a) to define a time value of absolute > 9 hours since 1. Jan. 1970

and further on impossible

(b) to represent a second offset > 32 microseconds.

This is rather ridiculous situation, so I wonder, why have two
int members been specified? A more reasonable decision
would be something like

typedef struct {
    implementation_defined sec;    /* seconds since 1 Jan. 1970
00:00:00 */
    implementation_defined nsec;   /* nanoseconds since time specified
by sec */
} xtime;

with a possible additional constraint along the line of:

"The members sec and nsec are both implementation-defined,
signed integral types and their corresponding member digit of
their numeric_limits specialization shall be at least 31 bit."

(A value of 31 bit guarantees that nsec just can reach up
to ~2 seconds, which is perfectly sufficient)

Greetings from Bremen,

Daniel Kr   gler


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr=FCgler wrote:
> N2285, which can be found at
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2285.html#xtim=
e
>=20
> defines the structure xtime as follows:
>=20
> typedef struct {
>     int sec;    /* seconds since 1 Jan. 1970 00:00:00 */
>     int nsec;   /* nanoseconds since time specified by sec */
> } xtime;
>=20
> IMO this specification leads to problematic situation related
> to the point, how one can portably define such a structure
> with a time value of some milliseconds, which is a rather
> mild request for usual hardware.

That's going to go away, as hinted in the second bullet item under "Open=20
Issues."

--=20

 -- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and=20
Reference." (www.petebecker.com/tr1book)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr=C3=BCgler ha scritto:
>=20
> typedef struct {
>     implementation_defined sec;    /* seconds since 1 Jan. 1970
> 00:00:00 */
>     implementation_defined nsec;   /* nanoseconds since time specified
> by sec */
> } xtime;
>=20
> with a possible additional constraint along the line of:
>=20
> "The members sec and nsec are both implementation-defined,
> signed integral types and their corresponding member digit of
> their numeric_limits specialization shall be at least 31 bit."

std::int_least32_t, perhaps?

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 25, 6:21 pm, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> Daniel Kr   gler ha scritto:
[..]
> > with a possible additional constraint along the line of:
>
> > "The members sec and nsec are both implementation-defined,
> > signed integral types and their corresponding member digit of
> > their numeric_limits specialization shall be at least 31 bit."
>
> std::int_least32_t, perhaps?

I considered a similar specification, Ganesh, but decided against
it, because I could not find convincing arguments that
std::int_least32_t is more reasonable than e.g. std::int_fast32_t.

But if one of the <cstdint> types is preferred compared to
an explicit description (as above), then std::int_fast32_t seems
more appropriate than std::int_least32_t, don't you think so?

Greetings from Bremen,

Daniel


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]