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