Deutsch English Français Italiano |
<pan$e9fd5$1a1eef8b$c3e30623$375931ee@linux.rocks> View for Bookmarking (what is this?) Look up another Usenet article |
From: Farley Flud <ff@linux.rocks> Subject: Re: Can't Avoid That Shit Rust - Even On Gentoo Newsgroups: comp.os.linux.advocacy,comp.os.linux.misc Followup-To: comp.os.linux.advocacy References: <pan$96411$d204da43$cc34bb91$1fe98651@linux.rocks> <5mqdnZuGq4lgwm_7nZ2dnZfqnPSdnZ2d@earthlink.com> <9tDIO.25203$afc4.21891@fx42.iad> <llgvjcF5rlhU3@mid.individual.net> <59JIO.96321$WtV9.10707@fx10.iad> <vd8bou$15h6g$2@dont-email.me> <18udnd3mEtEGfGX7nZ2dnZfqnPGdnZ2d@earthlink.com> <vdap5d$1kp35$4@dont-email.me> <fcKcnSXE3MsnqWf7nZ2dnZfqnPudnZ2d@earthlink.com> <D0rKO.165127$EEm7.5633@fx16.iad> <vddevg$24fps$4@dont-email.me> <llv1scFa6uvU1@mid.individual.net> <D-6cnfCih5UIy2f7nZ2dnZfqn_adnZ2d@earthlink.com> <slrnvflggs.lr8.candycanearter07@candydeb.host.invalid> <pan$177f8$17178cab$c1086257$7a39b6f7@linux.rocks> <Btycnd1FwtZrW2H7nZ2dnZfqnPednZ2d@earthlink.com> Mime-Version: 1.0 Message-Id: <pan$e9fd5$1a1eef8b$c3e30623$375931ee@linux.rocks> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lines: 51 Path: ...!news-out.netnews.com!netnews.com!s1-4.netnews.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!news.usenetexpress.com!not-for-mail Date: Wed, 02 Oct 2024 09:49:26 +0000 Nntp-Posting-Date: Wed, 02 Oct 2024 09:49:26 +0000 X-Received-Bytes: 2810 X-Complaints-To: abuse@usenetexpress.com Organization: UsenetExpress - www.usenetexpress.com Bytes: 3078 On Wed, 2 Oct 2024 00:07:15 -0400, 186282@ud0s4.net wrote: >> >> GNU/Linux has had 64-bit time for many years already. > > It's not just HAVING 64/128-bit vars. Gotta look > at every function, every line. The original pgmr > likely specified 32-bit vars for a of of the > date-related stuff because, well, datetime is > always 32 bit, right ? Hey, the cdates/mdates > on FILES too ...... > If the programmer follows ISO/POSIX standards then it will all automatically become 64-bit because all libc time/date functions are based on time_t, which is an integer defined in the libc headers. Some filesystem timestamps may still be 32-bit but that shouldn't be hard to fix. If the filesytem is in wide usage it should be fixed already. > The swamp just gets deeper and deeper. > > There are kind of the literal gazillion bits of > code in dozens of languages created from the > late 1950s on that are inside apps/systems > everywhere today that in some way deal > with, depend on, datetimes. > Most C source code from the 1950's, or even the 1990's, would not on run on current 64-bit systems anyway, irrespective of date/time functions. I have had to convert code from the early 2000's just to make it run on my machine. The change from 32 to 64 bit processors forced many, many packages to be rewritten. But you are correct. Lot's of code won't make it but for desktop GNU/Linux workstations this code is largely irrelevant and may be irrelevant elsewhere as well. -- Systemd: solving all the problems that you never knew you had.