From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: * X-Spam-Status: No, score=1.0 required=3.0 tests=BAYES_20,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: C time_t 2038 problem s-os_lib.ads Date: Thu, 23 Sep 2021 12:52:30 -0700 Organization: None to speak of Message-ID: <874kabm5mp.fsf@nosuchdomain.example.com> References: <8936f386-3fdb-43b3-b912-317906d59631n@googlegroups.com> <4431fad9-d297-4d68-8c0f-fa771c6710f6n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="8bcb0bda835272ce79dfeccf3aad56df"; logging-data="14941"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1986MSHHr9MtCQhl1Iz0cDB" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:5agJg+/V+fAFlDoMz7Yv5oupmOo= sha1:pW4yYXhQGSRXHQePxQoILdtFAHY= Xref: reader02.eternal-september.org comp.lang.ada:62830 List-Id: Joakim Strandberg 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 */