[tz] make error

[Paul Eggert]

On 2023-11-18 15:01, Steffen Nurpmeso wrote:

> I program in ISO C89, but have some macros which use C99 features
> if available (mostly named aka indexed initializers).

It would take significant work to port today's tzcode to C89 since zic.c 
depends so heavily on 64-bit integers, which are required by C99 but not 
C89. This has been true since release 2006b, and this dependence can't 
easily be worked around via macros.

This dependency should be stated more clearly in the commentary; 
proposed patch attached. As the patch notes, there may be dependencies 
on other extensions to C89, though I lack time to check.


> Use of generics

These are needed for platforms where integers have padding. On these 
platforms tzcode won't work with C89 because C89 lacks _Generic. 
Admittedly platforms with integer padding are rare - though I've used 
one in the last week, by coincidence.


> 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++).

tzcode is written in C not C++, and I doubt whether it's worth the 
maintenance hassle to port it to C++.


> The checked integer things ckd_*().  Only look at that.  How TZ
> code is now a preprocessor mess

The idea is to write clean C23 code, and that eventually (in 2053, say) 
we can remove the obsolete code. In the meantime the C23 code serves as 
the model for the obsolete stuff, so it is commentary on older platforms.

Unfortunately it's tricky to implement ckd_add and ckd_mul in macros 
that would work on almost all pre-C23 platforms. Although I've done it, 
the resulting code is LGPLed and I don't want to place it into the 
public domain. So tzcode makes do with awkward #ifdefs instead. (All I 
can say for tzcode is, wait until 2053! :-)

This is not an issue of efficiency: it's an issue of writing clean C23 
code where the pre-C23 variants are adequate approximations.


> 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?

I'm not sure what is meant by the question. ckd_add (*A, B, C) stores 
into *A the low-order bits of the mathematical sum of B and C, and 
returns true if the result overflowed (that is, if the resulting *A does 
not equal the mathematical sum of B and C). *A, B, and C must be 
integers but need not be the same integer type. So yes, it should work 
regardless of the widths of ptrdiff_t and size_t. (C23 requires two's 
complement so there's no ambiguity about what "low-order bits" means.)


> And one more, all the hobby projects, all the historians

It's not our goal to port to all platforms that have ever existed. 
Porting to currently-used platforms is good enough. Hobbyist historians 
should be using old versions of tzcode anyway.

The rule of thumb is: when a platform's supplier doesn't support the 
platform any more, we needn't worry about supporting it either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Document-limits-and-hazards-of-C89-support.patch
Type: text/x-patch
Size: 4333 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20231119/f97e2eff/attachment.bin>