In article <8kfsu5$lnh@news-central.tiac.net>, Stan Ryckman
<stanr@tiac.RemoveThis.net> writes
>>Not at all.  time_t is required to have arithmetic properties, as
>>it is an arithmetic type.
>
>I'm not so sure of that... legal time_t values might be
>trap representations of the underlying arithmetic type for
>arithmetic computations

I'm not sure that the Standard can be read in that way. Since trap
representations aren't assignable, such a value can't be returned by
library calls.

>I'm not sure that one can even compare two time_t values for equality
>without introducing undefined behavior,

Again, I would say that that was the intention of specifying it was an
arithmetic type.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sebastian Moleski wrote:

> Please show me the reference into the C++ Standard that forces long to =
be at
> least 32 bits.

If this is not true, then there's a error in my favorite C++ book. The C+=
+
Programming Language 3rd ed. 1st printing :) section 4.6 Sizes:

1 =3D=3D sizeof(char) <=3D sizeof(short) <=3D sizeof(int) <=3D sizeof(lon=
g)

1<=3D sizeof(bool) <=3D sizeof(long)

sizeof(char) <=3D sizeof(wchar_t) <=3D sizeof(long)

sizeof(float) <=3D sizeof(double) <=3D sizeof(long double)

sizeof(N) =3D=3D sizeof(signed N) =3D=3D sizeof(unsigned N)

where N can be char, short int, int or long int. In addition, it is guara=
nteed
that a char has at least 8 bits, a short at least 16 bits, and a long at =
least
32 bits.


--

Claude Qu=E9zel (claude_quezel@syntell.corba)
anti-spam: replace corba by com in private replies


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper" <kuyper@wizard.net>:
> Sebastian Moleski wrote:
> >
> > "James Kuyper" <kuyper@wizard.net>:
> > > Sebastian Moleski wrote:
> > > > ....
> > > >
> > > > Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) <<
sizeof(long).
> > > >
> > > > That also means that they all could be 8 bits of size.
> > >
> > > You've forgotten <climits>. C++ inherits from C the requirement that
> > > SHRT_MAX be at least 32767. How could that be consistent with an 8 bit
>                 ^^^^^^^^
> > > short?
> >
> > Where is it said that SHRT_MAX *must* be 32767?
>
> Nowhere. I didn't say that it did - reread the marked phrase above.
>
> Section 18.2p4 of the C++ standard says "SEE ALSO: ISO C subclause
> 7.1.5, 5.2.4.2.2, 5.2.4.2.1". The relevant section of the C standard for
> the requirement that SHRT_MAX >= 32767 is 5.2.4.2.1.

If SHRT_MAX defines the maximum size of a short in C++ as well, it
contradicts with the part of the C++ Standard I quoted before. Maybe this
should be a cause for a DR?

Regards,

Sebastian Moleski


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sebastian Moleski wrote:

> "James Kuyper" <kuyper@wizard.net>:
> > Sebastian Moleski wrote:

> > > "James Kuyper" <kuyper@wizard.net>:
> > > > Sebastian Moleski wrote:
> > > > > ....

> > > > > Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) <<
> sizeof(long).

> > > > > That also means that they all could be 8 bits of size.

> > > > You've forgotten <climits>. C++ inherits from C the requirement that
> > > > SHRT_MAX be at least 32767. How could that be consistent with an 8 bit
> >                 ^^^^^^^^
> > > > short?

> > Section 18.2p4 of the C++ standard says "SEE ALSO: ISO C subclause
> > 7.1.5, 5.2.4.2.2, 5.2.4.2.1". The relevant section of the C standard for
> > the requirement that SHRT_MAX >= 32767 is 5.2.4.2.1.

> If SHRT_MAX defines the maximum size of a short in C++ as well, it
> contradicts with the part of the C++ Standard I quoted before. Maybe this
> should be a cause for a DR?


You mean : "  Therefore, sizeof(char) <= sizeof(short) <=
      sizeof(int) << sizeof(long). " ?
That's indeed another requirement of the standard. But how does it contradict
the requirement on SHRT_MAX?

The standard allows[1] sizeof(char) == sizeof (short) == sizeof (int)
if and only if a char can be 32767, too.

Michiel Salters

[1] There is a slight problem with int getc(); if sizeof(char)==sizeof(int).

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sebastian Moleski wrote:
>
> "James Kuyper" <kuyper@wizard.net>:
> > Sebastian Moleski wrote:
> > >
> > > "James Kuyper" <kuyper@wizard.net>:
> > > > Sebastian Moleski wrote:
> > > > > ....
> > > > >
> > > > > Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) <<
> sizeof(long).
> > > > >
> > > > > That also means that they all could be 8 bits of size.
> > > >
> > > > You've forgotten <climits>. C++ inherits from C the requirement that
> > > > SHRT_MAX be at least 32767. How could that be consistent with an 8 bit
> >                 ^^^^^^^^
> > > > short?
> > >
> > > Where is it said that SHRT_MAX *must* be 32767?
> >
> > Nowhere. I didn't say that it did - reread the marked phrase above.
> >
> > Section 18.2p4 of the C++ standard says "SEE ALSO: ISO C subclause
> > 7.1.5, 5.2.4.2.2, 5.2.4.2.1". The relevant section of the C standard for
> > the requirement that SHRT_MAX >= 32767 is 5.2.4.2.1.
>
> If SHRT_MAX defines the maximum size of a short in C++ as well, it
> contradicts with the part of the C++ Standard I quoted before. Maybe this
> should be a cause for a DR?

It sets the mininum size of a short.

One requirement is that sizeof(char) <= sizeof(short) <= sizeof(int).
Another is that char be at least 8 bits, short be at least 16 bits, and
int be at least 16 bits. There is no conflict.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
> James Kuyper wrote:
> >
> > Greg Brewer wrote:
....
> > In C99, you can write the following:
> >
> > #include <stdint.h>
> > #ifdef INT64_MAX
> >         // The optional type with exactly 64 bits exists
> >         int64_t f(void);
> > #else
> >         // The type with at least 64 bits is mandatory
> >         int_least64_t f(void);
> > #endif
> >
> > I think you can reasonably assume that future versions of the C++
> > standard will borrow this feature of C99. C++ compilers that share code
> > with C99 compilers will probably provide <stdint.h> as an extension much
> > earlier than that.
>
> However, in C++, you could do it better with templates:
[Details of a templated implementation of sized integer types ]
> Now you could write
>
> int_type<30>::fastest i;
>
> and could be sure that you get the fastest type with at
> least 30 bits. That's far more flexible than the C solution
> (which helps only for the common sizes).

The C solution allows other sizes, it just doesn't require them. In C99
<stdint.h> is allowed to typedef intN_t for any value of N; if it does
that typedef must represent an exactly N-bit integer, along with all the
corresponding macros. Similarly for the other sized integer types, such
as int_leastN_t. Implementing int_leastN_t efficiently for arbitrary N
would call for a bit of compiler magic, but it would be possible and
legal.

Still, I take your point.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3967AD6E.61FE2B91@null.net>
Douglas A. Gwyn <DAGwyn@null.net> writes:
>Usurping a value to return an error (or EOF) indication was
>very common in the UNIX C library.  It is pretty well understood
>now that that is not the best way to design function interfaces.

I'd like to think that people know better now, but i'm not so sure.

It may be interesting that earlier conventions, when people wrote in
assembler, are often something like, the carry bit is set on error, and
this is always checked first, so again the error is out of band.

I've worked with coding guidelines which say that all functions should
return an error code, and any actual data is passed back via parameters.
Over time, i'm only more convinced that this is the way to go.

New functions can be provided which follow this.

--
Joe Keane, amateur mathematician

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8ks20j$snf$1@rocky.jgk.org>, Joe Keane  <jgk@jgk.org> wrote:
>In article <3967AD6E.61FE2B91@null.net>
>I've worked with coding guidelines which say that all functions should
>return an error code, and any actual data is passed back via parameters.
>Over time, i'm only more convinced that this is the way to go.
>
>New functions can be provided which follow this.

Um, do you really mean _all_ functions?  Somehow I don't think this
will work very well.  How would one write nontrivial expressions
containing function calls?  For example, how would one write the
equivalent of the present-day C/C++ expression

   #include <math.h>
   /* ... */
   double fn = exp(-2.0*beta)
        * (sin(2*phi)*cos(theta) + log(cos(2*phi)*sin(theta)));

if each of those trancendental function calls had to return its "real"
result via a parameter?  We'd end up basically writing assembler code,
with temp variables for each function call.  No thanks!

Yes,  errno  is a well-known wart in C/C++'s <math.h>.  Yes, it's a
performance hit for multithreading.  Yes, it's hard to use effectively.
Yes, IEEE nans aren't well-supported in pre-C99 C, and still require
nonstandard hacks to use effectively.  Yes, they have their own performance
problems.  (Not to mention lots of user problems too.)

But I think the proposed solution would be even worse.

[For C I don't know what would be better, but C++ exceptions provide
a possible solution to this problem.]

--
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   http://www.thp.univie.ac.at/~jthorn/home.html
   Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
   "Think about it.  Would you work for a company that couldn't tell the
    difference in quality of its employees' normal work product and the
    work product of someone on drugs without performing a test?"  -- anon

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8kvgn9$ee9$1@mach.thp.univie.ac.at>,
Jonathan Thornburg <jthorn@galileo.thp.univie.ac.at> wrote:
>In article <8ks20j$snf$1@rocky.jgk.org>, Joe Keane  <jgk@jgk.org> wrote:
>>In article <3967AD6E.61FE2B91@null.net>
>>I've worked with coding guidelines which say that all functions should
>>return an error code, and any actual data is passed back via parameters.
>>Over time, i'm only more convinced that this is the way to go.
>>
>>New functions can be provided which follow this.
>
>Um, do you really mean _all_ functions?  Somehow I don't think this
>will work very well.  How would one write nontrivial expressions
>containing function calls?  For example, how would one write the
>equivalent of the present-day C/C++ expression
>
>   #include <math.h>
>   /* ... */
>   double fn = exp(-2.0*beta)
>        * (sin(2*phi)*cos(theta) + log(cos(2*phi)*sin(theta)));
>
>if each of those trancendental function calls had to return its "real"
>result via a parameter?  We'd end up basically writing assembler code,
>with temp variables for each function call.  No thanks!
>
>Yes,  errno  is a well-known wart in C/C++'s <math.h>.  Yes, it's a
>performance hit for multithreading.  Yes, it's hard to use effectively.
>Yes, IEEE nans aren't well-supported in pre-C99 C, and still require
>nonstandard hacks to use effectively.  Yes, they have their own performance
>problems.  (Not to mention lots of user problems too.)

Yes, he probably means all functions and, yes, you are correct about
the consequences.  However, you have missed a few delightful "gotchas"
in both C90 and C99 (and almost certainly C++):

    A) If two of those function calls set errno, then the behaviour
is undefined.  So the only correct way to write standard C is not to
call more than one library function between two sequence points,
anyway.  Autocode, anyone?

    B) Once you start dabbling with 'IEEE' support in C99, there are
similar constraints for similar reasons.  At a very late stage, C99
was 'clarified' to state that the IEEE flags do not have object
semantics, but you won't always get the effect you expect if you
have more than one operation or function call in an expression.

    C) If the implementation uses the traditional and best fail
safe approach (i.e. an interrupt), it is virtually impossible to
conform with C90, let alone C99.  So it isn't done.

There are many ways of handling error returns correctly, and Joe
Keane's approach is only one.  All of the following work, and are
reliable and efficient WHEN DESIGNED AND IMPLEMENTED CORRECTLY:

    1) Always returning an error indication.

    2) Accumulating error flags until (say) a function return.

    3) Returning and percolating an error value.

    4) Raising an exception.

    5) Calling an alternate return (e.g. SNOBOL).

    6) And probably others ....

Unfortunately, in all cases, we don't want to start from here.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"David R Tribble" <david@tribble.com>:
> Ron Natalie wrote:
> > The standard doesn't require an 8 bit type.  It doesn't require a 16
> > bit type.  It doesn't require a 32 bit type.
>
> If you mean "require an exact 8-bit type", etc., yes, you are correct.
>
> > The only requirement is that there is a type at least 16 bits and
> > that the progression of char, short, int, long gives you types that
> > are either the same or greater in size each step.
>
> This implies that all the integer types could be 16 bits wide, which
> is incorrect.
>
> The requirements are that:
>  - 'char'   must hold at least 8 bits
>  - 'short'  must hold at least 16 bits
>  - 'int'    must hold at least 16 bits
>  - 'long'   must hold at least 32 bits
>  - 'float'  must hold at least 6 (decimal) digits
>  - 'double' must hold at least 10 (decimal) digits

Not true. In 3.9.1.2 C++ Standard 1998, it says
<<There are four signed integer types: "signed char", "short int", "int",
and "long int." In this list, each type provides at least as much storages
as those preceding it in the list. Plain ints have the natural size
suggested by the architecture of the execution environment; the other signed
integer types are provided to meet special needs.>>

Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) << sizeof(long).

That also means that they all could be 8 bits of size.

Regards,

Sebastian Moleski


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Jack Klein" <jackklein@spamcop.net>:
> On Wed, 28 Jun 2000 06:52:48 CST, "Greg Brewer"
> <nospam.greg@brewer.net> wrote in comp.std.c++:
>
> > I just discovered that Borland C++ supports types of __int64, __int32,
> > __int16, and __int8.  Is this standard or an extension?  Does MS or any
> > other C++ support it?
> >
> > Greg Brewer
>
> There are no C++ standard types that begin with two underscores.
> Microsoft has at least some of these type, but they are not standard.
>
> The longest integer type required in a conforming C++ implementation
> is long, that must contain at least 32 bits, but may contain more.

Please show me the reference into the C++ Standard that forces long to be at
least 32 bits.

TIA,

Sebastian Moleski


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sebastian Moleski wrote:
....
> Not true. In 3.9.1.2 C++ Standard 1998, it says
> <<There are four signed integer types: "signed char", "short int", "int",
> and "long int." In this list, each type provides at least as much storages
> as those preceding it in the list. Plain ints have the natural size
> suggested by the architecture of the execution environment; the other signed
> integer types are provided to meet special needs.>>
>
> Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) << sizeof(long).
>
> That also means that they all could be 8 bits of size.

You've forgotten <climits>. C++ inherits from C the requirement that
SHRT_MAX be at least 32767. How could that be consistent with an 8 bit
short?

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper" <kuyper@wizard.net>:
> Sebastian Moleski wrote:
> > ....
> >
> > Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) << sizeof(long).
> >
> > That also means that they all could be 8 bits of size.
>
> You've forgotten <climits>. C++ inherits from C the requirement that
> SHRT_MAX be at least 32767. How could that be consistent with an 8 bit
> short?

Where is it said that SHRT_MAX *must* be 32767?

Regards,

Sebastian Moleski



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sebastian Moleski wrote:
>
> "James Kuyper" <kuyper@wizard.net>:
> > Sebastian Moleski wrote:
> > > ....
> > >
> > > Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) << sizeof(long).
> > >
> > > That also means that they all could be 8 bits of size.
> >
> > You've forgotten <climits>. C++ inherits from C the requirement that
> > SHRT_MAX be at least 32767. How could that be consistent with an 8 bit
                ^^^^^^^^
> > short?
>
> Where is it said that SHRT_MAX *must* be 32767?

Nowhere. I didn't say that it did - reread the marked phrase above.

Section 18.2p4 of the C++ standard says "SEE ALSO: ISO C subclause
7.1.5, 5.2.4.2.2, 5.2.4.2.1". The relevant section of the C standard for
the requirement that SHRT_MAX >= 32767 is 5.2.4.2.1.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Sebastian Moleski wrote:
....
> Please show me the reference into the C++ Standard that forces long to be at
> least 32 bits.

Section 18.2.2p4, which contains a cross-reference to section 5.2.4.2.1
of the C standard, which requires that LONG_MAX >=2147483647.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Sebastian Moleski" <sebmol@gmx.net> wrote:
> Not true. In 3.9.1.2 C++ Standard 1998, it says
> <<There are four signed integer types: "signed char", "short int", "int",
> and "long int." In this list, each type provides at least as much storages
> as those preceding it in the list. Plain ints have the natural size
> suggested by the architecture of the execution environment; the other signed
> integer types are provided to meet special needs.>>
>
> Therefore, sizeof(char) <= sizeof(short) <= sizeof(int) << sizeof(long).
>
> That also means that they all could be 8 bits of size.

No it doesn't. Section 18 also places some requirements on the minimum
and maximum values that may be stored in shorts/ints/longs. These values
come from the C standard and mean that a long can not be shorter than 32
bits.

Paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:
[...]
> (time_t)-1 is perfectly portable. Assuming that time_t has arithmetic
> properties is what isn't portable.

Assuming that time_t *doesn't* have arithmetic properties is equally
non-portable.  Using -1 as an error indication imposes an unreasonable
constraint on implementations.  (I understand the historical reasons,
and I know it would be difficult to fix without breaking existing
code, but it is a Bad Thing.)

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

>And there are probably a few good ideas to borrow from outside C (I'm
>thinking specifically of Java's Date/Calendar/TimeZone classes).

Java's TimeZone classes are a good example of what _not_ to do.
The last time I checked, there was no way to implement accurate time
zone support that is compatible with Java's TimeZone abstract class.
This is because the designers of TimeZone didn't understand how
complicated time zone rules actually are in practice.  Even C89's time
primitives are better than Java's.


======================================= MODERATOR'S COMMENT:
 [ Warning, topic drift... -mod ]

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Greg Brewer wrote:
> >
> > That was my guess.  I was unsure about MS support.  It's one of those things
> > that I use if I must but avoid if I can.  I've been stuck on a problem
> > because I lack a 64bit integer; this allows me to proceed until a long long
> > becomes available.  I wish there was a way to detect its availability; sort
> > of a
> >   #if defined(long long)
> >       long long f(void);
> >   #else
> >       __int64 f(void);
> >   #endif
> > coding.
>
> In C99, you can write the following:
>
> #include <stdint.h>
> #ifdef INT64_MAX
>         // The optional type with exactly 64 bits exists
>         int64_t f(void);
> #else
>         // The type with at least 64 bits is mandatory
>         int_least64_t f(void);
> #endif
>
> I think you can reasonably assume that future versions of the C++
> standard will borrow this feature of C99. C++ compilers that share code
> with C99 compilers will probably provide <stdint.h> as an extension much
> earlier than that.

However, in C++, you could do it better with templates:

template<size_t n> struct int_type
{
  typedef ... exact;    // only defined if exact type exists
  typedef ... smallest; // defined for n<=some maximum value
  typedef ... fastest;  // dito
};

(Of course, there should also be typedefs for unsigned types)

F.ex. an implementation with 8-bit char, 16-bit short, 32-bit int
and 64-bit long, where int is the fastest type, could have the
definitions (assuming the template recursion limit is high enough):

template<size_t n> struct int_type
{
  typedef typename int_type<n+1>::smallest smallest;
  typedef typename int_type<n+1>::fastest fastest;
};

template<> struct int_type<8>
{
  typedef signed char exact;
  typedef signed char smallest;
  typedef int fastest;
};

template<> struct int_type<16>
{
  typedef short exact;
  typedef short smallest;
  typedef int fastest;
};

template<> struct int_type<32>
{
  typedef int exact;
  typedef int smallest;
  typedef int fastest;
};

template<> struct int_type<64>
{
  typedef long exact;
  typedef long smallest;
  typedef long fastest;
};

Now you could write

int_type<30>::fastest i;

and could be sure that you get the fastest type with at
least 30 bits. That's far more flexible than the C solution
(which helps only for the common sizes).

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble  <david@tribble.com> wrote:
>> Also, an unsigned time_t will not be able to represent times prior
>> to the epoch (e.g., 1970).  This is a problem already, though, since
>> ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
>> ISO didn't mandate a '_TIME_ERROR' macro instead.

Stan Ryckman wrote:
> Why do you see this as a problem already?  (time_t)(-1) for an
> unsigned time_t is just a way of writing U{time_t}_MAX without
> having to know what type time_t is.
>
> I do think it's stylistically ugly, but that's another matter.

Why not provide a _TIME_ERROR constant that represents an invalid
time_t value.  And why -1?  Why not ((time_t)INT_MIN)?

As I've asked before, why not have several macros that define the
range of time_t?:

    _TIME_ERROR          invalid time_t value, or error
    _TIME_MIN            minimum valid time_t value
    _TIME_MAX            maximum valid time_t value
    _TIME_TICKS_PER_SEC  resolution of time_t values

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes
>> Except of course that you can't do signed comparisons or differences
>> between time_t values reliably.  That's why POSIX defines time_t to
>> be a signed type.  (ISO C only specifies that it is an arithmetic
>> type.)
>>
>> Also, an unsigned time_t will not be able to represent times prior
>> to the epoch (e.g., 1970).  This is a problem already, though, since
>> ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
>> ISO didn't mandate a '_TIME_ERROR' macro instead.

Clive D.W. Feather wrote:
> Both of these statements seem to assume that time_t is a linear
> monotonic type; that is, that adding 1 to an (arithmetic) time_t is a
> meaningful thing to do.

No - my argument only assumes that some negative time_t values can
represent valid dates on some systems.

> It is quite legitimate *in ISO C* (POSIX has its own rules and must
> solve its own problems where they differ) for time_t to encode the
> time in some other manner. For example, it could be a collection of
> bitfields holding the various components of the time. The 1 bit does
> not have to represent the smallest unit of time; it could be that
> years are at that end and seconds at the sign bit end.
>
> In particular, (time_t)(-1) need not represent a valid time in that
> encoding.

But it certainly screws things up for systems in which (time_t)(-1)
does represent a valid time, doesn't it?  At the very least, it's
not very portable, is it?

Wouldn't having an explicit _TIME_ERROR macro be a bit cleaner?

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Douglas A. Gwyn" wrote:
>
> Paul Jarc wrote:
>> He means that even signed time_t can't be used to represent times
>> earlier than (time_t)0, because (time_t)-1 has already been
>> commandeered for something other than representing a time.
>
> Sure it can, but it means that *one* particular time can be
> confused with the error case.

Exactly.

> Usurping a value to return an error (or EOF) indication was
> very common in the UNIX C library.  It is pretty well understood
> now that that is not the best way to design function interfaces.

Except that the examples you're (probably) referring to, i.e.,
Unix system calls and I/O functions, the usurped values were not
also valid return values of those functions.  Unix system calls
returned positive values on success and -1 on error; character I/O
functions returned positive character codes or -1 on end of file.
And functions that return pointers return non-null pointers on
success and null on failure.

Returning a special value that otherwise can't be returned in order
to indicate an error is a perfectly acceptable practice (especially
if you don't have, or want, exception handling).

But stealing a perfectly good value from the middle of the time_t
range of values was a bad idea (which was my original point).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> David R Tribble <david@tribble.com> writes
> >Except of course that you can't do signed comparisons or differences
> >between time_t values reliably.  That's why POSIX defines time_t to
> >be a signed type.  (ISO C only specifies that it is an arithmetic
> >type.)
> >
> >Also, an unsigned time_t will not be able to represent times prior
> >to the epoch (e.g., 1970).  This is a problem already, though, since
> >ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
> >ISO didn't mandate a '_TIME_ERROR' macro instead.
"Clive D.W. Feather" wrote:
>
>
> Both of these statements seem to assume that time_t is a linear
> monotonic type; that is, that adding 1 to an (arithmetic) time_t is a
> meaningful thing to do.
>
> It is quite legitimate *in ISO C* (POSIX has its own rules and must
> solve its own problems where they differ) for time_t to encode the time
> in some other manner. For example, it could be a collection of bitfields
> holding the various components of the time. The 1 bit does not have to
> represent the smallest unit of time; it could be that years are at that
> end and seconds at the sign bit end.
>
> In particular, (time_t)(-1) need not represent a valid time in that
> encoding.




--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> Why not provide a _TIME_ERROR constant that represents an invalid
> time_t value.  And why -1?  Why not ((time_t)INT_MIN)?

I suspect you know the answer -- that's what was already implemented.
Frankly, I would not encourage the use of in-band signalling in any
new design for a function interface.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> Except that the examples you're (probably) referring to, i.e.,
> Unix system calls and I/O functions, the usurped values were not
> also valid return values of those functions.

Often they could be, but weren't normally in the limited contexts
of the early UNIX systems.  The plain fact is that there was a
common piece of run-time support code that set errno and returned
(int)-1, and it was taken as the canonical way to report an error
from a wide variety of functions, often a "no brainer" when some
brainwork should have been exerted instead.  If you rummage through
the legacy functions, you often run into (somepointer)-1 which is
simply disgusting.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <396A2B4F.7C6223AE@tribble.com>, David R Tribble
<david@tribble.com> writes
>As I've asked before, why not have several macros that define the
>range of time_t?:
>
>    _TIME_ERROR          invalid time_t value, or error
>    _TIME_MIN            minimum valid time_t value
>    _TIME_MAX            maximum valid time_t value
>    _TIME_TICKS_PER_SEC  resolution of time_t values

Because this is fiddling round the edges when we really need to redesign
from scratch.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <396A2CE2.5F34368D@tribble.com>, David R Tribble
<david@tribble.com> writes
>> In particular, (time_t)(-1) need not represent a valid time in that
>> encoding.
>
>But it certainly screws things up for systems in which (time_t)(-1)
>does represent a valid time, doesn't it?  At the very least, it's
>not very portable, is it?

(time_t)-1 is perfectly portable. Assuming that time_t has arithmetic
properties is what isn't portable.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ZWSwNMSn5ra5EweN@on-the-train.demon.co.uk>, "Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:
|> In article <396A2CE2.5F34368D@tribble.com>, David R Tribble
|> <david@tribble.com> writes
|> >> In particular, (time_t)(-1) need not represent a valid time in that
|> >> encoding.
|> >
|> >But it certainly screws things up for systems in which (time_t)(-1)
|> >does represent a valid time, doesn't it?  At the very least, it's
|> >not very portable, is it?
|>
|> (time_t)-1 is perfectly portable. Assuming that time_t has arithmetic
|> properties is what isn't portable.

Not at all.  time_t is required to have arithmetic properties, as
it is an arithmetic type.  Assuming that its arithmetic properties
bear any relationship to time as we know and love it (whether UTC
or other) is what isn't defined by the standard.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes
>> As I've asked before, why not have several macros that define the
>> range of time_t?:
>>    _TIME_ERROR          invalid time_t value, or error
>>    _TIME_MIN            minimum valid time_t value
>>    _TIME_MAX            maximum valid time_t value
>>    _TIME_TICKS_PER_SEC  resolution of time_t values

Clive D.W. Feather wrote:
> Because this is fiddling round the edges when we really need to
> redesign from scratch.

Good point.

So who is going to lead the charge for the redesigned time/date
library functions for C0X?  There are several good ideas contributed
by myself and others which would make a good starting point.  And
there are probably a few good ideas to borrow from outside C (I'm
thinking specifically of Java's Date/Calendar/TimeZone classes).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8kfkr7$pem$1@pegasus.csx.cam.ac.uk>,
Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>
>In article <ZWSwNMSn5ra5EweN@on-the-train.demon.co.uk>, "Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:
...
>|> (time_t)-1 is perfectly portable. Assuming that time_t has arithmetic
>|> properties is what isn't portable.
>
>Not at all.  time_t is required to have arithmetic properties, as
>it is an arithmetic type.

I'm not so sure of that... legal time_t values might be
trap representations of the underlying arithmetic type for
arithmetic computations (other than comparison for equality
to -1), as far as I can see.

I'm not sure that one can even compare two time_t values for equality
without introducing undefined behavior, though there does seem to
be at least an implication that it's OK if one of them is
(time_t)-1.

>Assuming that its arithmetic properties
>bear any relationship to time as we know and love it (whether UTC
>or other) is what isn't defined by the standard.

Agreed.

Stan

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Ryckman <stanr@tiac.RemoveThis.net> writes:
> In article <3964F817.E04EDBE5@tribble.com>,
> David R Tribble  <david@tribble.com> wrote:
> >Also, an unsigned time_t will not be able to represent times prior
> >to the epoch (e.g., 1970).  This is a problem already, though, since
> >ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
> >ISO didn't mandate a '_TIME_ERROR' macro instead.
>
> Why do you see this as a problem already?  (time_t)(-1) for an
> unsigned time_t is just a way of writing U{time_t}_MAX without
> having to know what type time_t is.

He means that even signed time_t can't be used to represent times
earlier than (time_t)0, because (time_t)-1 has already been
commandeered for something other than representing a time.


paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Ryckman <stanr@tiac.RemoveThis.net> writes:
> In article <3964F817.E04EDBE5@tribble.com>,
> David R Tribble  <david@tribble.com> wrote:
>
> [snip]
>
> >Also, an unsigned time_t will not be able to represent times prior
> >to the epoch (e.g., 1970).  This is a problem already, though, since
> >ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
> >ISO didn't mandate a '_TIME_ERROR' macro instead.
>
> Why do you see this as a problem already?  (time_t)(-1) for an
> unsigned time_t is just a way of writing U{time_t}_MAX without
> having to know what type time_t is.

It's a problem if time_t is signed, because it inserts an invalid
value in the middle of the representable range.  (On typical current
implementations, it means that 1969-12-31 23:59:59 is an error.)

If time_t is unsigned, using -1 isn't a problem (the error value is at
the end of the representable range) -- but making time_t unsigned
makes it impossible to represent times before the epoch.

The proper solution, IMHO, is:
    Make time_t signed.
    Make its range unreasonably big (64 bits should do it).
    Use a macro for the error value, and put it at the far end
    of the range (say, -2**63).
    And, of course, continue to allow for variations (e.g.,
    granularities finer than second).

All of these are compatible with the current standard except the macro
for an error value.

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Followup to:  <8k55rk$jhq@news-central.tiac.net>
By author:    Stan Ryckman <stanr@tiac.RemoveThis.net>
In newsgroup: comp.std.c
>
> In article <3964F817.E04EDBE5@tribble.com>,
> David R Tribble  <david@tribble.com> wrote:
>
> [snip]
>
> >Also, an unsigned time_t will not be able to represent times prior
> >to the epoch (e.g., 1970).  This is a problem already, though, since
> >ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
> >ISO didn't mandate a '_TIME_ERROR' macro instead.
>
> Why do you see this as a problem already?  (time_t)(-1) for an
> unsigned time_t is just a way of writing U{time_t}_MAX without
> having to know what type time_t is.
>
> I do think it's stylistically ugly, but that's another matter.
>

Because at least on Unix/POSIX platforms (time_t)(-1) is a legal value
representing Dec 31, 1969 23:59:59 GMT (UTC didn't exist until the
early 70's).

 -hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc wrote:
> He means that even signed time_t can't be used to represent times
> earlier than (time_t)0, because (time_t)-1 has already been
> commandeered for something other than representing a time.

Sure it can, but it means that *one* particular time can be
confused with the error case.

Usurping a value to return an error (or EOF) indication was
very common in the UNIX C library.  It is pretty well understood
now that that is not the best way to design function interfaces.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"H. Peter Anvin" <hpa@zytor.com> writes:

>Because at least on Unix/POSIX platforms (time_t)(-1) is a legal value
>representing Dec 31, 1969 23:59:59 GMT (UTC didn't exist until the
>early 70's).

Actually, UTC did exist back then, though not in the same form as today
(as it didn't have leap seconds).  As a standard, GMT became obsolete
in the 1920s.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3964F817.E04EDBE5@tribble.com>, David R Tribble
<david@tribble.com> writes
>Except of course that you can't do signed comparisons or differences
>between time_t values reliably.  That's why POSIX defines time_t to
>be a signed type.  (ISO C only specifies that it is an arithmetic
>type.)
>
>Also, an unsigned time_t will not be able to represent times prior
>to the epoch (e.g., 1970).  This is a problem already, though, since
>ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
>ISO didn't mandate a '_TIME_ERROR' macro instead.

Both of these statements seem to assume that time_t is a linear
monotonic type; that is, that adding 1 to an (arithmetic) time_t is a
meaningful thing to do.

It is quite legitimate *in ISO C* (POSIX has its own rules and must
solve its own problems where they differ) for time_t to encode the time
in some other manner. For example, it could be a collection of bitfields
holding the various components of the time. The 1 bit does not have to
represent the smallest unit of time; it could be that years are at that
end and seconds at the sign bit end.

In particular, (time_t)(-1) need not represent a valid time in that
encoding.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Microsoft uses an epoch starting at 1601-01-01 00:00:00.000 GMT
> (counting backward from the current calendar and ignoring the
> historical Gregorian calendric change in 1585/1752), with 100 nsec
> ticks (even though you can only retrieve system times to the nearest
> millisecond).  But all of the Microsoft C libraries implement a
> 32-bit time_t based on the 1970 epoch.  (They even embed 32-bit
> time_t dates within their object files.)

Microsoft C/C++ 7 used a time_t counting seconds from 1899-12-31
(or was it an option?) Quite a nuisance, probably, so they revert
back. The funny part is that they explained that was for ANSI C
compatibility...


Antoine

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:
[...]
> >Also, an unsigned time_t will not be able to represent times prior
> >to the epoch (e.g., 1970).  This is a problem already, though, since
> >ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
> >ISO didn't mandate a '_TIME_ERROR' macro instead.
>
> Both of these statements seem to assume that time_t is a linear
> monotonic type; that is, that adding 1 to an (arithmetic) time_t is a
> meaningful thing to do.
>
> It is quite legitimate *in ISO C* (POSIX has its own rules and must
> solve its own problems where they differ) for time_t to encode the time
> in some other manner. For example, it could be a collection of bitfields
> holding the various components of the time. The 1 bit does not have to
> represent the smallest unit of time; it could be that years are at that
> end and seconds at the sign bit end.
>
> In particular, (time_t)(-1) need not represent a valid time in that
> encoding.

That's true, but using (time_t)(-1) as an error indication does poke a
hole in the representable range for the most convenient representation
on many systems (a signed integer type with a linear monotonic mapping
to real time).  A macro like TIME_ERROR would allow an appropriate
value to be chosen for any representation.  Unfortunately, this would
be a difficult change to make (a lot of existing code depends on
(time_t)(-1) as an error value) unless we initially mandate
TIME_ERROR == (time_t)(-1).

Though it's too late to fix for C99, it would be nice (IMHO) if a
future standard were to guarantee monotonicity and uniqueness (though
not necessarily linearity) for time_t.  This would allow safe use of
relational operators on time_t values.  If monotonicity is too much of
a burden (are there any implementations that aren't monotonic?), at
least uniqueness would be good.  More specifically, even if time_t has
more than one representation for a given time, the standard could
guarantee that any standard function that returns a time_t always
returns a unique value for any time.

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> I just discovered that Borland C++ supports types of __int64, __int32,
> __int16, and __int8.  Is this standard or an extension?  Does MS or any
> other C++ support it?

It's an extension. As a general rule, identifiers starting with '_' are
likely to be implementation specific. Exceptions: __LINE__, __FILE__,
__DATE__, __TIME__, __STDC__, __cplusplus. There may be more exceptions
that I've missed; it's difficult to search a PDF file for strings
starting with '_'.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 28 Jun 2000, Greg Brewer wrote:

> I just discovered that Borland C++ supports types of __int64, __int32,
> __int16, and __int8.  Is this standard or an extension?  Does MS or any
> other C++ support it?

The existence of the three smallest types is guaranteed on any 32-bit
implementation... you might just find them under a different name
(although people here might argue that C++ does not technically require
_int16 any more than it requires _int7).  _int64 is required for some
Microsoft functions (and by extension potentially any program) to
function properly.  All _int64's functions are provided in the standard
libraries, and not in the compiler.  Thus _int64 functions may (will) be
rewritten for IA-64/Sledgehammer.

Richard.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Yes MS support these type.


"Greg Brewer" <nospam.greg@brewer.net> wrote in message
news:8jb3kt$1kig$1@news.hal-pc.org...
> I just discovered that Borland C++ supports types of __int64, __int32,
> __int16, and __int8.  Is this standard or an extension?  Does MS or any
> other C++ support it?
>
> Greg Brewer
>
>
> ---
> [ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]
>

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 28 Jun 2000 06:52:48 CST, "Greg Brewer"
<nospam.greg@brewer.net> wrote in comp.std.c++:

> I just discovered that Borland C++ supports types of __int64, __int32,
> __int16, and __int8.  Is this standard or an extension?  Does MS or any
> other C++ support it?
>
> Greg Brewer

There are no C++ standard types that begin with two underscores.
Microsoft has at least some of these type, but they are not standard.

The longest integer type required in a conforming C++ implementation
is long, that must contain at least 32 bits, but may contain more.

The recent 1999 update to the C language standard requires conforming
C implementations provide an integer type named "long long" that must
contain at least 64 bits.  Note that this C update is not part of the
C++ standard, although it seems likely that it will be added.

The new C update also defines typedefs for exact width integers (names
like int8_t, uint8_t, and so on) but a compiler is not required to
provide exact width types, since not all processor architectures have
natural support for type that come in exact multiples of 8 bits.

There are other typedefs in C99 for integer types "at least" n bits
wide, and the fastest type "at least" n bits wide.  These typedefs
might be more difficult to incorporate into C++, but that of course if
up to the committee.

Jack Klein
--
Home: http://jackklein.home.att.net

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Said nospam.greg@brewer.net (Greg Brewer) in comp.std.c++:
>I just discovered that Borland C++ supports types of __int64, __int32,
>__int16, and __int8.  Is this standard or an extension?  Does MS or any
>other C++ support it?

The leading double underscore is a good tipoff that it's non-
standard. Borland has quite properly created these identifiers out
of the set of names reserved to the implementation.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                  http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
illegal identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> On Wed, 28 Jun 2000, Greg Brewer wrote:
>
> > I just discovered that Borland C++ supports types of __int64, __int32,
> > __int16, and __int8.  Is this standard or an extension?  Does MS or any
> > other C++ support it?
>
> The existence of the three smallest types is guaranteed on any 32-bit
> implementation... you might just find them under a different name

Perhaps, but that guarantee isn't part of the C++ standard. I'm curious
- what is it a part of? I've heard of 32-bit implementations that
violated that guarantee: 8-bit char, 32-bit short, int, long, float, and
pointer, 64-bit double. Therefore, it's not a guarantee that follows
logically just from being a 32-bit implementation.

> (although people here might argue that C++ does not technically require
> _int16 any more than it requires _int7).  _int64 is required for some

"might" argue? Why do you have any doubt about it? "technically"? What's
technical about the fact that '_int16' has no more support in the
standard than 'shortest' or 'longer'? It's a pure extension, with no
connection to the C++ standard of any kind.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> On Wed, 28 Jun 2000, Greg Brewer wrote:
>
> > I just discovered that Borland C++ supports types of __int64, __int32,
> > __int16, and __int8.  Is this standard or an extension?  Does MS or any
> > other C++ support it?
>
> The existence of the three smallest types is guaranteed on any 32-bit
> implementation... you might just find them under a different name
> (although people here might argue that C++ does not technically require
> _int16 any more than it requires _int7).

The standard doesn't require an 8 bit type.  It doesn't require a 16 bit type.
It doesn't require are 32 bit type.  The only requirement is that there is a type
at least 16 bits and that the progression of char, short, int, long gives you
types that are either the same or greater in size each step.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

That was my guess.  I was unsure about MS support.  It's one of those things
that I use if I must but avoid if I can.  I've been stuck on a problem
because I lack a 64bit integer; this allows me to proceed until a long long
becomes available.  I wish there was a way to detect its availability; sort
of a
  #if defined(long long)
      long long f(void);
  #else
      __int64 f(void);
  #endif
coding.

Greg


> >I just discovered that Borland C++ supports types of __int64, __int32,
> >__int16, and __int8.  Is this standard or an extension?  Does MS or any
> >other C++ support it?
>
> The leading double underscore is a good tipoff that it's non-
> standard. Borland has quite properly created these identifiers out
> of the set of names reserved to the implementation.



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
> The standard doesn't require an 8 bit type.  It doesn't require a 16
> bit type.  It doesn't require a 32 bit type.

If you mean "require an exact 8-bit type", etc., yes, you are correct.

> The only requirement is that there is a type at least 16 bits and
> that the progression of char, short, int, long gives you types that
> are either the same or greater in size each step.

This implies that all the integer types could be 16 bits wide, which
is incorrect.

The requirements are that:
 - 'char'   must hold at least 8 bits
 - 'short'  must hold at least 16 bits
 - 'int'    must hold at least 16 bits
 - 'long'   must hold at least 32 bits
 - 'float'  must hold at least 6 (decimal) digits
 - 'double' must hold at least 10 (decimal) digits

The ISO C++ requirements are borrowed from the ISO C requirements,
in ANSI/ISO 9899-1990, 5.2.4.2.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Brewer" <nospam.greg@brewer.net> wrote...
> That was my guess.  I was unsure about MS support.  It's one of
> those things that I use if I must but avoid if I can.  I've been
> stuck on a problem because I lack a 64bit integer; this allows me
> to proceed until a long long becomes available.  I wish there was
> a way to detect its availability; sort of a
>   #if defined(long long)
>       long long f(void);
>   #else
>       __int64 f(void);
>   #endif
> coding.

You look like a man who needs a typedef. At least then you only
have to fiddle with one line of code when you change compiler.

   #if defined(__STDC_VERSION__)
       typedef long long int64_t;
   #else
       typedef __int64 int64_t;
   #endif

   int64_t f(void);

Better still (since it is likely to be the direction that C++ takes
in future) you might look into the C9X "stdint.h" header, which
you can (probably?) pick up from www.boost.org.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie <ron@sensor.com> writes:
> The standard doesn't require an 8 bit type.  It doesn't require a 16
> bit type.  It doesn't require are 32 bit type.  The only requirement
> is that there is a type at least 16 bits and that the progression of
> char, short, int, long gives you types that are either the same or
> greater in size each step.

Long is required to be at least 32 bits.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I thought about it.

My concern is mktime which will max out early in 2038.  I have a number of
data structures that are read from disk with 32 bit time fields.  My
structure also has an integer basedate field which is zero for now.  My plan
is to create a mktime64 function that will return the 64 bit elapsed time
since 1970.  I have an idea or two on how to do it just no time.  I also
plan to create a function that will return the 64bit time from the basedate
and the 32 bit field.   basedate will probably be some multiple of number of
years so that
   ts64 = ts32 + basedate * numberofyears
and number of years will probably be some mutlple of 4.  That will carry me
until Feb of 2100.  Hopefully, the question will be moot by then.

Greg


"Daniel M. Pfeffer" <pfefferd@nospam.internet-zahav.net> wrote in message
news:newscache$uel4xf$zvi$1@lnews.actcom.co.il...
> How about writing a class that behaves like a 64-bit integer? On a 32-bit
> architecture, the compiler must typically simulate 64-bit operations with
> multiple 32-bit operations. There is no reason why you cannot write
> more-or-less portable code that does the same, and is reasonably
efficient.
> Daniel Pfeffer



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> I thought about it.
>
> My concern is mktime which will max out early in 2038.  I have a number of
> data structures that are read from disk with 32 bit time fields.  My
> structure also has an integer basedate field which is zero for now.

The DEC-10 processors had an "epoch" bump when they ran out of bits in the
late 70's.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote in message <8jqed1$1ejg$1@news.hal-pc.org>...
>I thought about it.
>
>My concern is mktime which will max out early in 2038.
[...]
>That will carry me
>until Feb of 2100.  Hopefully, the question will be moot by then.

If the year 2100 is all you care about, you don't need 64-bit numbers.
Just switch to unsigned!  The extra bit will buy you another 68 years
and you'll be ok until 2106.

- Anders

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> I thought about it.
>
> My concern is mktime which will max out early in 2038.  I have a
> number of data structures that are read from disk with 32 bit time
> fields.  My structure also has an integer basedate field which is
> zero for now.  My plan is to create a mktime64 function that will
> return the 64 bit elapsed time since 1970.  I have an idea or two on
> how to do it just no time.  I also plan to create a function that
> will return the 64bit time from the basedate and the 32 bit field.
> basedate will probably be some multiple of number of years so that
>    ts64 = ts32 + basedate * numberofyears
> and number of years will probably be some mutlple of 4.  That will
> carry me until Feb of 2100.  Hopefully, the question will be moot by
> then.

Take a look at my proposal at
 <http://david.tribble.com/text/c0xtime.htm>.

My proposal uses a 64-bit signed integer time type, yielding date
values from BC 9999 to AD 9999 (all possible four-digit year values)
with microsecond accuracy.

Other proposals include one by Markus Kuhn at
 <http://www.cl.cam.ac.uk/~mgk25/c-time/>,
and one by Paul Eggert at
 <http://www.twinsun.com/tz/timeapi.html>.

You'll have to deal with leap seconds, timezones, etc., in order to
be reasonably complete.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> My concern is mktime which will max out early in 2038.

Only for 32-bit Unix.  Implementations with 64-bit time_t values
will not be affected (although transferring data files between the
two types of systems is problematic).  IBM OS/390 uses a 64-bit clock,
but it will also run out of bits in 2047.  Windows uses a 64-bit
clock internally, but implements time_t as a 32-bit int, so it has
the same problem as 32-bit Unix.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Anders J. Munch" <andersjm@dancontrol.dk> writes:
> Greg Brewer wrote in message <8jqed1$1ejg$1@news.hal-pc.org>...
> >That will carry me
> >until Feb of 2100.  Hopefully, the question will be moot by then.
>
> If the year 2100 is all you care about, you don't need 64-bit numbers.
> Just switch to unsigned!  The extra bit will buy you another 68 years
> and you'll be ok until 2106.

Switching to unsigned will also lose the ability to represent times
before the epoch (1970 in this case).

Systems are naturally evolving to support 64-bit integers.  Long
before signed 32-bit time_t runs out in 2038, I predict that typical
systems will have at least signed 64-bit time_t.  (It may also be
common for time_t to have a granularity finer than 1 second, perhaps
64 bits signed for the number of seconds and 64 bits unsigned for
fractions of a second.)

If you need to represent times in the future, you need to use
something other than time_t.  If all you're concerned about is, say,
file creation timestamps, you might as well stick with time_t *and*
make sure your code doesn't depend on its representation.  When future
systems solve the Y2.038K problem (or Y0.9951171875K if you prefer),
just recompile your code (and possibly convert your data files if
you've written time_t values to long-term storage).

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Greg Brewer wrote:
> >
> > My concern is mktime which will max out early in 2038.
>
> Only for 32-bit Unix.  Implementations with 64-bit time_t values
> will not be affected (although transferring data files between the
> two types of systems is problematic).  IBM OS/390 uses a 64-bit clock,
> but it will also run out of bits in 2047.  Windows uses a 64-bit
> clock internally, but implements time_t as a 32-bit int, so it has
> the same problem as 32-bit Unix.

The epochs are different as well.  Doesn't the IBM use 1900?

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[Cross-posted to comp.std.c  -drt]

Ron Natalie wrote:
>
> David R Tribble wrote:
>>
>> Greg Brewer wrote:
>> >
>> > My concern is mktime which will max out early in 2038.
>>
>> Only for 32-bit Unix.  Implementations with 64-bit time_t values
>> will not be affected (although transferring data files between the
>> two types of systems is problematic).  IBM OS/390 uses a 64-bit
>> clock, but it will also run out of bits in 2047.  Windows uses a
>> 64-bit clock internally, but implements time_t as a 32-bit int,
>> so it has the same problem as 32-bit Unix.
>
> The epochs are different as well.  Doesn't the IBM use 1900?

IBM OS/390 uses a 64-bit counter which counts the number of ticks
since 1900-01-01 00:00:00.000.  Each tick is 2**-12 microseconds,
thus the upper 32 bits is a "large" second of 2**20 microseconds.
It's also already an unsigned value (the upper bit flipped over
several years ago).  But it still has the same problem as 32-bit
POSIX, in that its end of epoch date is less than 50 years away.

Microsoft uses an epoch starting at 1601-01-01 00:00:00.000 GMT
(counting backward from the current calendar and ignoring the
historical Gregorian calendric change in 1585/1752), with 100 nsec
ticks (even though you can only retrieve system times to the nearest
millisecond).  But all of the Microsoft C libraries implement a
32-bit time_t based on the 1970 epoch.  (They even embed 32-bit
time_t dates within their object files.)

Embedded 32-bit POSIX time_t values are quite pervasive.  PGP uses
them for its encryption timestamps, for example.  No telling how
many other physical file formats contain 32-bit POSIX time_t
values that may survive the next 40 years.  Moving to a 64-bit
representation is only half the battle; converting existing data
files will be the (quite large) other half.  That effort will not
begin in 40 years, but has already started.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[Cross-posted to comp.std.c  -drt]

Greg Brewer wrote in message <8jqed1$1ejg$1@news.hal-pc.org>...
>> My concern is mktime which will max out early in 2038.
> [...]
>> That will carry me
>> until Feb of 2100.  Hopefully, the question will be moot by then.

Anders J. Munch wrote:
> If the year 2100 is all you care about, you don't need 64-bit numbers.
> Just switch to unsigned!  The extra bit will buy you another 68 years
> and you'll be ok until 2106.

Except of course that you can't do signed comparisons or differences
between time_t values reliably.  That's why POSIX defines time_t to
be a signed type.  (ISO C only specifies that it is an arithmetic
type.)

Also, an unsigned time_t will not be able to represent times prior
to the epoch (e.g., 1970).  This is a problem already, though, since
ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
ISO didn't mandate a '_TIME_ERROR' macro instead.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

As amusing context for the discussion of time/dates and how long they last, I
recommend Vernor Vinge's fine science-fiction novel "A Deepness in The Sky",
which includes a profession called software archaelogist, i.e., someone who
rummages around the layers of old software to figure out how to do
something.   [The story is set several thousand years from now].

In learning this profession, the protagonist (Pham Nuwen) is incensed
to find layers of junk and old assumptions. For example, he complains
that all the  layers of software think that time started about the time of the
first moon landing on Old Earth, except they didn't quite get it right,
and hit 1970 instead :-)
--
-John Mashey EMAIL:  mash@sgi.com  DDD: 650-933-3090 FAX: 650-933-2663
USPS:   SGI 1600 Amphitheatre Pkwy., ms. 562, Mountain View, CA 94043-1351

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3964F817.E04EDBE5@tribble.com>,
David R Tribble  <david@tribble.com> wrote:

[snip]

>Also, an unsigned time_t will not be able to represent times prior
>to the epoch (e.g., 1970).  This is a problem already, though, since
>ISO C defines '(time_t)(-1)' to represent an error value.  Pity that
>ISO didn't mandate a '_TIME_ERROR' macro instead.

Why do you see this as a problem already?  (time_t)(-1) for an
unsigned time_t is just a way of writing U{time_t}_MAX without
having to know what type time_t is.

I do think it's stylistically ugly, but that's another matter.

Stan

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> That was my guess.  I was unsure about MS support.  It's one of those things
> that I use if I must but avoid if I can.  I've been stuck on a problem
> because I lack a 64bit integer; this allows me to proceed until a long long
> becomes available.  I wish there was a way to detect its availability; sort
> of a
>   #if defined(long long)
>       long long f(void);
>   #else
>       __int64 f(void);
>   #endif
> coding.

In C99, you can write the following:

#include <stdint.h>
#ifdef INT64_MAX
 // The optional type with exactly 64 bits exists
 int64_t f(void);
#else
 // The type with at least 64 bits is mandatory
 int_least64_t f(void);
#endif

I think you can reasonably assume that future versions of the C++
standard will borrow this feature of C99. C++ compilers that share code
with C99 compilers will probably provide <stdint.h> as an extension much
earlier than that.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi !

Greg Brewer wrote:
> ...
> I just discovered that Borland C++ supports types of __int64, __int32,
> __int16, and __int8.  Is this standard or an extension?  Does MS or any
> other C++ support it?
> ...

 Ye, MS Visual C++ does support these types (don't know about others).
And no, they are not standard. It is an extension.

Best regards,
Andrey.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

> Greg Brewer wrote:
> >
> > That was my guess.  I was unsure about MS support.  It's one of those things
> > that I use if I must but avoid if I can.  I've been stuck on a problem
> > because I lack a 64bit integer; this allows me to proceed until a long long
> > becomes available.  I wish there was a way to detect its availability; sort
> > of a
> >   #if defined(long long)
> >       long long f(void);
> >   #else
> >       __int64 f(void);
> >   #endif
> > coding.
>
> In C99, you can write the following:
>
> #include <stdint.h>
> #ifdef INT64_MAX
>  // The optional type with exactly 64 bits exists
>  int64_t f(void);
> #else
>  // The type with at least 64 bits is mandatory
>  int_least64_t f(void);
> #endif
>
> I think you can reasonably assume that future versions of the C++
> standard will borrow this feature of C99. C++ compilers that share code
> with C99 compilers will probably provide <stdint.h> as an extension much
> earlier than that.

hm... since most (all?) of <stdint.h> can be implemented as typedefs,
  (well, actually that assumes already having a 64 bit integral type;
  I guess I am too used to the ubiquity of 'long long' on unices)
  I would suspect it will be a matter of whether <stdint.h> comes with
  the compiler / c library.

(As one example, gcc (freestanding C compiler) does not support
  int64_t and friends. However, if the system C library has
  <stdint.h>, (linux with glibc >= 2.1.2 being one example), int64_t
  etc work fine with C++, as they are only typedefs. )

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

llewellyat@dbritschdot.dsldot.xmissiondot.com wrote:
....
> hm... since most (all?) of <stdint.h> can be implemented as typedefs,

<stdint.h> includes a fair number of macros.

>   (well, actually that assumes already having a 64 bit integral type;
>   I guess I am too used to the ubiquity of 'long long' on unices)

C99 requires the existence of 'long long', int_least64_t, int_fast64_t,
and intmax_t, all of which are required to be at least 64 bits.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Brewer" <nospam.greg@brewer.net> wrote in message
news:8jd8f2$27pk$1@news.hal-pc.org...
> That was my guess.  I was unsure about MS support.  It's one of those
things
> that I use if I must but avoid if I can.  I've been stuck on a problem
> because I lack a 64bit integer; this allows me to proceed until a long
long
> becomes available.  I wish there was a way to detect its availability;
sort
> of a
>   #if defined(long long)
>       long long f(void);
>   #else
>       __int64 f(void);
>   #endif
> coding.
>
> Greg
>
>
> > >I just discovered that Borland C++ supports types of __int64, __int32,
> > >__int16, and __int8.  Is this standard or an extension?  Does MS or any
> > >other C++ support it?
> >
> > The leading double underscore is a good tipoff that it's non-
> > standard. Borland has quite properly created these identifiers out
> > of the set of names reserved to the implementation.

How about writing a class that behaves like a 64-bit integer? On a 32-bit
architecture, the compiler must typically simulate 64-bit operations with
multiple 32-bit operations. There is no reason why you cannot write
more-or-less portable code that does the same, and is reasonably efficient.


Daniel Pfeffer


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I just discovered that Borland C++ supports types of __int64, __int32,
__int16, and __int8.  Is this standard or an extension?  Does MS or any
other C++ support it?

Greg Brewer


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]