comp.lang.ada
 help / color / mirror / Atom feed
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Subject: Re: C time_t 2038 problem s-os_lib.ads
Date: Thu, 23 Sep 2021 12:52:30 -0700	[thread overview]
Message-ID: <874kabm5mp.fsf@nosuchdomain.example.com> (raw)
In-Reply-To: cd4a94de-e8b9-4194-8d80-24a009a558ban@googlegroups.com

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 */

  parent reply	other threads:[~2021-09-23 19:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23 10:42 C time_t 2038 problem s-os_lib.ads Kevin Chadwick
2021-09-23 14:26 ` Jeffrey R. Carter
2021-09-23 15:01   ` Kevin Chadwick
2021-09-23 15:08     ` Joakim Strandberg
2021-09-23 15:39       ` Kevin Chadwick
2021-09-23 15:57         ` Kevin Chadwick
2021-09-23 19:52       ` Keith Thompson [this message]
2021-09-24  9:32         ` Joakim Strandberg
2021-09-24  9:44           ` Niklas Holsti
2021-09-24 22:54           ` Keith Thompson
2021-09-25 10:22             ` G.B.
2021-09-25 11:23             ` Simon Wright
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox