[tz] make error

[Steffen Nurpmeso]

Philip Paeps via tz wrote in
 <07734306-4216-483D-A547-CC72A2016C45 at 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)