Re: time_t size: The year 2038 bug?

[Khimenko Victor]

In <[e-mail]> Jesse Pollard ([e-mail]) wrote:
> From: Jakub Jelinek <[e-mail]>
>>On Thu, Jan 06, 2000 at 08:53:23PM -0500, Johan Kullstam wrote:
>>> Thierry Vignaud <[e-mail]> writes:
>>>
>>> > Jesse Pollard a écrit :
>>> > >
>>> > > Johan Kullstam" <[e-mail]>
>>> > > >i'd also like to see C types with *specified* bit widths, e.g.,
>>> > > >int16, int32, uint8 &c.  then you could write more portable code when
>>> > > >you really need a certain number of bits like for CRC algorithms.
>>> >
>>> > ever head of inttypes.h ???
>>>
>>> consider a 64 bit processor where you'd like to have 64 bit integers.
>>> use the following:
>>>
>>> type        bits
>>> char           8
>>> short int     16
>>> int           64
>>> long int      64
>>> long long    128
>>>
>>> ok now that we have no 32 bit integer quantity, please get me a 32 bit
>>> integer using a #define macro.
>>
>>Its up to stdint.h to provide you correct typedefs for int8_t, int16_t,
>>int32_t, int64_t. E.g. with gcc, it is easy,
>>e.g. on archs with char type 8bit large with
>>typedef int int32_t __attribute__((mode (SI)));
>>even if int is 64bit as well as long,
>>and I think other compilers have their ways of doing something similar as
>>well.
>>128bit long long is very uncommon these days on the other side, even on
>>64bit architectures.

> Oh, I don't know about that -- I can think of several applications that
> use up to 4096 bit integers. How about SSL, PGP, IP v 6 addresses are 128 bit,
> IPSec might use "long" ints. DES could use 56 bit integers. Right now these
> applications do all of the arithmetic in C library functions that define
> the arithemtic.

No. They doing it with hand-written assembler functions.

> Wouldn't it be more efficient if it could be implemented directly in the
> language?

No. You can not beat assembler. When you have REALLY time-consuming function
it's better to do with assembler. And when you do not need to operate with
data but just must move it around you do not need any support from language:
char[something] will do just fine.

On other hand if you have not-so-time-critical-functions such new syntax can
help to write more clear code.

> My reply was addressing the need for variable length integers not necessarily
> supported in hardware available sizes. No header may define an int larger
> than that supported by hardware (the "sizeof(int)" thing), without a
> nonstandard C compiler. The bitfield syntax appeared to fit the bill with
> a minimum of alteration in the grammar or symantic alterations.

> Such a construct would allow integers on any sized platform for source
> code compatability. It requires the compiler/runtime system to generate
> the appropriate operations to support the language.

> <rant on>
> I realize this is an off-topic reply, but the entire thread appeared to be
> off-topic, since POSIX defines what the size of time_t is going to be.

> One UNIX system I have used had ints limited to 16 bits. Guess what- time_t was
> defined as:

> typedef int   time_t[2];

> Is this an accepable substitute? not really, but it worked. Could date
> arithmetic be done easily? no. It was all nonstandard, calling assembly
> library functions to perform the arithemtic (add, sub, mul, div, test).

> All that was required was that it work.
> <rant off :)>

> I do think that an addition to the compiler (nonstandard of course) that
> allowed integers to be defined as "int var : 36;" would be very usefull,
> and may solve many related problems. I haven't addressed the use of
> constants here... (um, how about ddddddddddddd:ddB form where d is a digit,
> :dd is the length, and B is a base indicator - H for hex digits, D for
> decimal)

Ask gcc folks about such additions :-) You do not need ANSI or ISO approval
to add such construct and use it (if you tried to compile open-source programs
with, say, native Solaris compiler you seen that LOTS of open-source programs
are written with usage of gcc extensions anyway).