C time_t 2038 problem s-os_lib.ads

C time_t 2038 problem s-os_lib.ads

[Kevin Chadwick]

I have noticed that C time_t appears to be Long_integer in Gnat s-os_lib.ads.

Just wondering if it should be 64bit long long as OpenBSD has already moved to long long?

There seemed to be some noise on Twitter about the Linux Kernel side last year but I'm not sure if that ended up just being noise without action or not.

"https://www.openbsd.org/papers/eurobsdcon_2013_time_t/"

p.s. It's interesting that Adas type system avoids this issue mostly (ignoring leap handling pain) 

Re: C time_t 2038 problem s-os_lib.ads

[Jeffrey R. Carter]

On 9/23/21 12:42 PM, Kevin Chadwick wrote:
> I have noticed that C time_t appears to be Long_integer in Gnat s-os_lib.ads.
> 
> Just wondering if it should be 64bit long long as OpenBSD has already moved to long long?

GNAT defines

    type Long_Integer is range -(2 **63) .. +(2 **63 - 1);
    for Long_Integer'Size use 64;

-- 
Jeff Carter
"I was either in love, or I had smallpox."
Take the Money and Run
137

Re: C time_t 2038 problem s-os_lib.ads

[Kevin Chadwick]

On Thursday, September 23, 2021 at 2:26:11 PM UTC, Jeffrey R. Carter wrote:
> On 9/23/21 12:42 PM, Kevin Chadwick wrote: 
> > I have noticed that C time_t appears to be Long_integer in Gnat s-os_lib.ads. 
> > 
> > Just wondering if it should be 64bit long long as OpenBSD has already moved to long long?
> GNAT defines 
> 
> type Long_Integer is range -(2 **63) .. +(2 **63 - 1); 
> for Long_Integer'Size use 64; 
> 

I see, thank you.

GPS doesn't seem to jump to declaration for Long_Integer and grep hasn't turned it up, 
so I will just take your word for it.

Re: C time_t 2038 problem s-os_lib.ads

[Joakim Strandberg]

torsdag 23 september 2021 kl. 17:01:04 UTC+2 skrev m8il...@gmail.com:
> On Thursday, September 23, 2021 at 2:26:11 PM UTC, Jeffrey R. Carter wrote: 
> > On 9/23/21 12:42 PM, Kevin Chadwick wrote: 
> > > I have noticed that C time_t appears to be Long_integer in Gnat s-os_lib.ads. 
> > > 
> > > Just wondering if it should be 64bit long long as OpenBSD has already moved to long long? 
> > GNAT defines 
> > 
> > type Long_Integer is range -(2 **63) .. +(2 **63 - 1); 
> > for Long_Integer'Size use 64; 
> >
> I see, thank you. 
> 
> GPS doesn't seem to jump to declaration for Long_Integer and grep hasn't turned it up, 
> so I will just take your word for it.

Well, yes Long_Integer is 64-bits, but long long in cpp is 128 bits which sounds like a discrepancy to me. On OpenBSD it indicates C time_t should be changed from Long_Integer to somethinge else that is 128-bits.  All packages in Ada has "with Standard; use Standard;" which brings Integer etc. into scope. Long_Integer should be defined in the Standard package. Under help in GPS it should be possible to find the Standard package.

Best regards,
Joakim

Re: C time_t 2038 problem s-os_lib.ads

[Kevin Chadwick]

> Well, yes Long_Integer is 64-bits, but long long in cpp is 128 bits which sounds like a discrepancy to me. On OpenBSD it indicates C time_t should be changed from Long_Integer to somethinge else that is 128-bits. 

I'm not sure OpenBSD uses c++ but their long long is 64 bits; seconds since Jan 1970. I guess this demonstrates an Ada strength.

> All packages in Ada has "with Standard; use Standard;" which brings Integer etc. into scope. Long_Integer should be defined in the Standard package. Under help in GPS it should be possible to find the Standard package. 

Thank You. I have found it.

I expected it to jump to declaration if I included Long_Integer in a compiling program text but 
it doesn't seem to work for types. Oh well.

Regards, Kc

Re: C time_t 2038 problem s-os_lib.ads

[Kevin Chadwick]

> > All packages in Ada has "with Standard; use Standard;" which brings Integer etc. into scope. Long_Integer should be defined in the Standard package. Under help in GPS it should be possible to find the Standard package.
> Thank You. I have found it. 

Strange, The package Standard file shows Long_Integer as range 64bit.
VsCode during hover on Long_Integer shows 32 bit, as it's range.

Re: C time_t 2038 problem s-os_lib.ads

[Keith Thompson]

Joakim Strandberg <joakimds@kth.se> writes:
> torsdag 23 september 2021 kl. 17:01:04 UTC+2 skrev m8il...@gmail.com:
>> On Thursday, September 23, 2021 at 2:26:11 PM UTC, Jeffrey R. Carter wrote: 
>> > On 9/23/21 12:42 PM, Kevin Chadwick wrote: 
>> > > I have noticed that C time_t appears to be Long_integer in Gnat s-os_lib.ads. 
>> > > 
>> > > Just wondering if it should be 64bit long long as OpenBSD has already moved to long long? 
>> > GNAT defines 
>> > 
>> > type Long_Integer is range -(2 **63) .. +(2 **63 - 1); 
>> > for Long_Integer'Size use 64; 

Does it do that on all operating systems?  C's type long is 32 bits on
64-bit Windows.  (Of course Ada's Long_Integer doesn't have to match C's
long.)

>> I see, thank you. 
>> 
>> GPS doesn't seem to jump to declaration for Long_Integer and grep hasn't turned it up, 
>> so I will just take your word for it.
>
> Well, yes Long_Integer is 64-bits, but long long in cpp is 128 bits
> which sounds like a discrepancy to me. On OpenBSD it indicates C
> time_t should be changed from Long_Integer to somethinge else that is
> 128-bits.  All packages in Ada has "with Standard; use Standard;"
> which brings Integer etc. into scope. Long_Integer should be defined
> in the Standard package. Under help in GPS it should be possible to
> find the Standard package.

If by "cpp" you mean C++, I've never seen an implementation where long
long is 128 bits (or anything other than exactly 64 bits).

In C and C++, int is required to be at least 16 bits (POSIX requires
32), long is at least 32 bits, and long long is at least 64 bits.  On
most 64-bit Linux-based systems, int is 32 bits, and long and long long
are both 64 bits.  On 64-bit MS Windows, int and long are both 32 bits,
and long long is 64 bits.  time_t is 64 bits on almost all 64-bit
systems.  I've never seen a 128-bit time_t; 64 bits with 1-second
resolution is good for several hundred billion years.

If an Ada implementation makes Integer, Long_Integer, and
Long_Long_Integer correspond to C and C++'s int, long, and long long,
then on a system (e.g.,. Windows) where long is 32 bits, defining time_t
as Long_Integer is going to cause problems in 2038 -- *and* it's likely
not going to match the system's C and C++ time_t definition.

I don't see a definition of "time_t" in s-os_lib.ads on my system.

If an Ada implementation is going to define a type that's intended to
match C's time_t, it should match the representation of that C type.
I presume GNAT gets this right.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Re: C time_t 2038 problem s-os_lib.ads

[Joakim Strandberg]

> In C and C++, int is required to be at least 16 bits (POSIX requires 
> 32), long is at least 32 bits, and long long is at least 64 bits. On 
> most 64-bit Linux-based systems, int is 32 bits, and long and long long 
> are both 64 bits. On 64-bit MS Windows, int and long are both 32 bits, 
> and long long is 64 bits. time_t is 64 bits on almost all 64-bit 
> systems. I've never seen a 128-bit time_t; 64 bits with 1-second 
> resolution is good for several hundred billion years. 

Thanks for the summary of different types of integers on different platforms Keith. When I wrote above I had simply done a quick Google search and found https://www.tutorialspoint.com/what-is-long-long-in-c-cplusplus where it said "On Linux environment the long takes 64-bit (8-bytes) of space, and the long long takes 128-bits (16-bytes) of space." I have never seen 128-bit integers either but have seen on the development log on AdaCore's website that support for 128-bit integers have been added to the Interfaces package (Interfaces.Integer_128 and Interfaces.Unsigned_128). I believe they are part of the new Ada2022 standard.

Best regards,
Joakim

Re: C time_t 2038 problem s-os_lib.ads

[Niklas Holsti]

On 2021-09-24 12:32, Joakim Strandberg wrote:
>> In C and C++, int is required to be at least 16 bits (POSIX
>> requires 32), long is at least 32 bits, and long long is at least
>> 64 bits. On most 64-bit Linux-based systems, int is 32 bits, and
>> long and long long are both 64 bits. On 64-bit MS Windows, int and
>> long are both 32 bits, and long long is 64 bits. time_t is 64 bits
>> on almost all 64-bit systems. I've never seen a 128-bit time_t; 64
>> bits with 1-second resolution is good for several hundred billion
>> years.
> 
> Thanks for the summary of different types of integers on different
> platforms Keith. When I wrote above I had simply done a quick Google
> search and found
> https://www.tutorialspoint.com/what-is-long-long-in-c-cplusplus where
> it said "On Linux environment the long takes 64-bit (8-bytes) of
> space, and the long long takes 128-bits (16-bytes) of space." I have
> never seen 128-bit integers either but have seen on the development
> log on AdaCore's website that support for 128-bit integers have been
> added to the Interfaces package (Interfaces.Integer_128 and
> Interfaces.Unsigned_128).


Good that they have been added.


> I believe they are part of the new Ada2022 standard.

I believe not. The draft Ada2022 RM still requires no specific integer 
widths in section B.2, "The Package Interfaces". As in earlier 
standards, it still says:

"An implementation shall provide the following declarations in the 
visible part of package Interfaces: - Signed and modular integer types 
of n bits, if supported by the target architecture, for each n that is 
at least the size of a storage element and that is a factor of the word 
size. The names of these types are of the form Integer_n for the signed 
types, and Unsigned_n for the modular types"

The change by AdaCore probably reflects the fact that gcc now supports 
128-bit integers on common platforms.

Wikipedia has a summary: https://en.wikipedia.org/wiki/128-bit_computing.

Re: C time_t 2038 problem s-os_lib.ads

[Keith Thompson]

Joakim Strandberg <joakimds@kth.se> writes:
>> In C and C++, int is required to be at least 16 bits (POSIX requires 
>> 32), long is at least 32 bits, and long long is at least 64 bits. On 
>> most 64-bit Linux-based systems, int is 32 bits, and long and long long 
>> are both 64 bits. On 64-bit MS Windows, int and long are both 32 bits, 
>> and long long is 64 bits. time_t is 64 bits on almost all 64-bit 
>> systems. I've never seen a 128-bit time_t; 64 bits with 1-second 
>> resolution is good for several hundred billion years. 
>
> Thanks for the summary of different types of integers on different
> platforms Keith. When I wrote above I had simply done a quick Google
> search and found
> https://www.tutorialspoint.com/what-is-long-long-in-c-cplusplus where
> it said "On Linux environment the long takes 64-bit (8-bytes) of
> space, and the long long takes 128-bits (16-bytes) of space." I have
> never seen 128-bit integers either but have seen on the development
> log on AdaCore's website that support for 128-bit integers have been
> added to the Interfaces package (Interfaces.Integer_128 and
> Interfaces.Unsigned_128). I believe they are part of the new Ada2022
> standard.

That web page is simply wrong about long long being 128 bits.  It
certainly can be (the C standard only says that it's at least 64 bits),
but it's exactly 64 bit on every implementation I've seen or heard of.

I'm not shocked that something on tutorialspoint.com is wrong.

There are several common data models in the C and C++ world:

Name       ILP32  LP64  IL32P64
====       =====  ====  =======
char       8      8     8
short      16     16    16
int        32     32    32
long       32     64    32
long long  64     64    64
pointer    32     64    64

32-bit systems (which are becoming rarer for non-embedded systems)
typically use ILP32, and 64-bit Linux/Unix systems typically use LP64.
64-bit Windows uses IL32P64 (and hardly anything else does).

It's *seems* almost obvious that Ada's types
    Character
    Short_Integer
    Integer
    Long_Integer
    Long_Long_Integer
should correspond to the similarly named C types, but it's not required.
(I don't know whether GNAT does so consistently or not.)

Some C and C++ compilers support 128-bit integers on 64-bit systems.
gcc supports "__int128" and "unsigned __int128", but they don't quite
meet all the C requirements for integer types; for example, there are no
literals of those types.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Re: C time_t 2038 problem s-os_lib.ads

[G.B.]

On 25.09.21 00:54, Keith Thompson wrote:

> 
> It's *seems* almost obvious that Ada's types
>      Character
>      Short_Integer
>      Integer
>      Long_Integer
>      Long_Long_Integer
> should correspond to the similarly named C types, but it's not required.
> (I don't know whether GNAT does so consistently or not.)
It might turn out as an advantage if Ada programs don't to use
types named like that.

First, the standard says an implementation MAY provide them.

Second, if Ada programs call C functions that take C int arguments,
then argument types taken from Interfaces.C seem to be the obvious
choice.

Just state what's needed in the type's definition in your program,
referring to "externally defined" types as required.

Re: C time_t 2038 problem s-os_lib.ads

[Simon Wright]

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> There are several common data models in the C and C++ world:
>
> Name       ILP32  LP64  IL32P64
> ====       =====  ====  =======
> char       8      8     8
> short      16     16    16
> int        32     32    32
> long       32     64    32
> long long  64     64    64
> pointer    32     64    64
>
> 32-bit systems (which are becoming rarer for non-embedded systems)
> typically use ILP32, and 64-bit Linux/Unix systems typically use LP64.
> 64-bit Windows uses IL32P64 (and hardly anything else does).
>
> It's *seems* almost obvious that Ada's types
>     Character
>     Short_Integer
>     Integer
>     Long_Integer
>     Long_Long_Integer
> should correspond to the similarly named C types, but it's not required.
> (I don't know whether GNAT does so consistently or not.)

Package Standard in FSF GCC 11.2.0 on macOS (which you can see by
compiling something with -gnatS) has

   type Integer is range -(2 **31) .. +(2 **31 - 1);
   for Integer'Size use 32;

   subtype Natural  is Integer range 0 .. Integer'Last;
   subtype Positive is Integer range 1 .. Integer'Last;

   type Short_Short_Integer is range -(2 **7) .. +(2 **7 - 1);
   for Short_Short_Integer'Size use 8;

   type Short_Integer is range -(2 **15) .. +(2 **15 - 1);
   for Short_Integer'Size use 16;

   type Long_Integer is range -(2 **63) .. +(2 **63 - 1);
   for Long_Integer'Size use 64;

   type Long_Long_Integer is range -(2 **63) .. +(2 **63 - 1);
   for Long_Long_Integer'Size use 64;

   type Long_Long_Long_Integer is range -(2 **127) .. +(2 **127 - 1);
   for Long_Long_Long_Integer'Size use 128;

I didn't know about the last, which is new in FSF GCC 11/GNAT CE 2021
... I could build my Analytical Engine simulator with 40 digit wheels
(i.e. capable of 40 decimal digits) instead of 50 using
Long_Long_Long_Integer instead of GNATColl.GMP.Integer.