Philip Paeps via tz wrote in <07734306-4216-483D-A547-CC72A2016C45@trouble.is>: |On 2023-11-18 03:20:41 (+0800), Paul Eggert via tz wrote: |> On 2023-11-17 00:30, Robert Elz wrote: |>> future version probably ought to be |>> rather distant future, not next year sometime (or even the next few |>> years |>> after that). |> |> Good point. From what we know now, 2029 might be a good year to do it, |> as RHEL 7 ELS ends June 2028. I installed the attached proposed patch. |> We can of course delay until after 2029 as more info becomes known. | |I think it's reasonable to expect everyone to have a C99 compiler by |2029. The standard will turn 30 years old that year. Even the most |tenacious long-term support systems will have run out of support by |then. Moreover: the poor souls stuck with maintaining those systems |will have ample experience installing newer compilers on them. | |Nobody will accuse the tz project of being hasty. Especially since |we're giving 5+ years notice. I personally do not understand the upgrade at all. I program in ISO C89, but have some macros which use C99 features if available (mostly named aka indexed initializers). Most new things of ISO are just terrible, and i sometimes love to read Ritchie's famous Article 7844 of comp.lang.c. Ie for most of ISO C i, in silence for myself ;), quote much of Ritchie, for example "Its chief virtue is that nearly everyone can forget about it", and "I'm not convinced that even [.] carry their weight". All the maintenance burden for things like "restrict" and other such things. Not even Rust has such, i think? Use of generics, static_assert() (becomes _really_ usable aka the same as the C++ one in ISO C23 -- after being nothing as an offense before: who thinks something like that? I see TZ also only uses that; one could use the C++ one 201103l++). I thus define my own [su_]CTA() and use _that_ (to have a clean namespace), and do use things i can pick up from compiler or C when available. The checked integer things ckd_*(). Only look at that. How TZ code is now a preprocessor mess that the real guys like Ritchie, Thompson and likely also Kernighan -- do not ask McIlroy! -- would nothing but run away from. Go read the wonderful manual page of Plan9's C compiler! ATTRIBUTE_REPRODUCIBLE static ptrdiff_t size_sum(size_t a, size_t b) { #ifdef ckd_add ptrdiff_t sum; if (!ckd_add(&sum, a, b) && sum <= INDEX_MAX) return sum; #else if (a <= INDEX_MAX && b <= INDEX_MAX - a) return a + b; #endif size_overflow(); } I presume ckd_add() (aka its actual incarnation which can be quite of a different sort) is then used to allow several compiler optimizations aka .. it is unbelievable how smart compilers sometimes are, aka how large their mathematical competence is. But nonetheless, the above is a maintenance nightmare. Is the above worth that hazzle? Ie a really smart compiler can very likely reduce that (a <= INDEX_MAX && b <= INDEX_MAX - a) without any ckd_*(), especially if INDEX_MAX==(size_t)-1, which it likely is, meaning the first is always true. ain:private.h:#define INDEX_MAX ((ptrdiff_t) min(PTRDIFF_MAX, SIZE_MAX)) Also with modern CPUs which massively speculate in parallel. And today, where even divisions "cost only a cycle" instead of (at least) fourty like around Y2K. If ptrdiff_t is 64-bit and size_t is 32-bit, too. If ptr is 32 and size is 64, then can ckd_*() add any value to the above conditional, treated by a smart optimizing compiler, without the special help of maybe hardware? And if so, how likely is it that such a smart compiler like gcc or clang does not get the notion of that 32-bit / 64-bit overflow problem? Isn't ckd_ a brainfart? Except that, granted, it is less error prone to use it instead of unrolling the above conditional, because the involved types are compiler deduced. Wow. ckd_*() is a fantastic innovation. And it results is code so nice as above. But whatever. All of the above (and all the things i erased again) does not require any other C standard than ISO C89, and there is no single positive aspect in deprecating elder standards at all. Not that i know. Except pseudo innovation, pseudo progress. What is important are code check tools like sanitizers, and also Coverity (and others; one may add clang's scan-build, but with that i have no good experience). During development my software randomizes the used ISO C version: # Prefer C99+ due to native 64-bit types etc ^ Yes. But there were __extension__s and ia64 or what even before. Yet they cause warnings unless disabled via compiler specifics. _i=c89 if feat_yes ASAN_ADDRESS || feat_yes USAN; then msg ' ! Disabling ISO C89 due to desire to use sanitizers' ^ Well. But isn't that an arbitrary pity? The latter, ok. _i= fi __x='c99 c11 c18 c2x '${_i} if feat_yes DEVEL && [ -n "${date}" ]; then __y=$(${date} +%M) # not too often if [ ${?} -eq 0 ]; then if [ -n "${good_shell}" ]; then ^ Yeah shells also have the evolution problem. __y=${__y##*0} else __y=$(echo ${__y} | ${sed} -e 's/^0*//') fi case "$((__y % 5))" in 0) __x=${_i}' c99 c11 c18 c2x';; 1) ;; 2) __x='c11 c18 c2x c99 '${_i};; 3) __x='c18 c2x c99 c11 '${_i};; 4) __x='c2x c99 c11 c18 '${_i};; esac fi unset __y fi for __x in ${__x}; do cc_check -std=${__x} && break done Let alone that almost _any_ change requires testing on lots of platforms because of all the compiler and include files etc bugs, and the compiler-version-specific miscompilations which still can happen. *All the quirks, everywhere*! And one more, all the hobby projects, all the historians which at home have dozens or hundreds of elder machines with elder software, and if only virtualized, they now can still compile TZ and have a current and correct date and time representation there, they would all be locked out for nothing. I am against deprecating ISO C89. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)