Nobody else admits to running such old compilers and systems! ;^> I would reduce that test to: #if __STDC_VERSION__ < 199901 # define restrict #endif In general for standards feature tests: #if defined(__STDC__) # define C89 # if defined(__STDC_VERSION__) # define C90 # if (__STDC_VERSION__ >= 199409L) # define C94 # endif # if (__STDC_VERSION__ >= 199901L) # define C99 # endif # if (__STDC_VERSION__ >= 201112L) # define C11 # endif # if (__STDC_VERSION__ >= 201710L) # define C17 # endif # if (__STDC_VERSION__ >= 202000L) /* TBD */ # define C2X # endif # endif #endif For updates see: $ info cpp macros predef standard also: https://en.wikipedia.org/wiki/Microsoft_Visual_C++#Internal_version_numberin... On 2023-11-16 12:58, Alois Treindl via tz wrote:

I fixed it by adding after private.h line 558:

It now reads

#if (__STDC_VERSION__ < 199901 && !defined restrict \      && (PORT_TO_C89 || defined _MSC_VER)) # define restrict #else # define restrict #endif

But I wonder why nobody stumbled upon this.

On 16.11.23 20:51, Alois Treindl via tz wrote:

...

I just made a new clone of tz.

I work normally on RHEL 7 (redhat enterprise Linux) with gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

When I say make or make all, I get something I never observed before:

cc -DTZDIR='"/usr/share/zoneinfo"'    -c -o zic.o zic.c In file included from zic.c:16:0: private.h:791:60: error: conflicting types for ‘restrict’  struct tm *localtime_rz(timezone_t restrict, time_t const *restrict,                                                             ^ private.h:791:36: note: previous definition of ‘restrict’ was here  struct tm *localtime_rz(timezone_t restrict, time_t const *restrict,                                     ^ private.h:792:15: error: conflicting types for ‘restrict’     struct tm *restrict);                ^ private.h:791:60: note: previous definition of ‘restrict’ was here  struct tm *localtime_rz(timezone_t restrict, time_t const *restrict,                                                             ^ private.h:793:49: error: conflicting types for ‘restrict’  time_t mktime_z(timezone_t restrict, struct tm *restrict);                                                  ^ private.h:793:28: note: previous definition of ‘restrict’ was here  time_t mktime_z(timezone_t restrict, struct tm *restrict);

This does not happen when I compile on RHEL 9 gcc version 11.4.1 20230605 (Red Hat 11.4.1-2) (GCC)

Can anyone point me to a fix?

-- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

Date: Thu, 16 Nov 2023 13:50:59 -0800 From: Guy Harris via tz <tz@iana.org> Message-ID: <B624A0FE-A94C-480F-8674-56D471E2104C@sonic.net> | what is the environment Alois is using defining restrict as? It almost certainly isn't defining it as anything (which would be why the change without the && "!defined restrict" worked - though that would only help if it was #defined, not defined some other way) - the error message that was shown clearly indicates that the compiler considered "restrict" to simply be a variable name (and then complained when it was used as the name for two different parameters - while giving var names in prototypes is unusual, as they accomplish nothing, it isn't prohibited, and if present they need to make sense, which having the same name twice, doesn't). That's what a compiler for a version of C from before "restrict" was added would naturally assume was happening. This does suggest though that for something like tzcode, which is used everywhere, requiring C99 anytime soon might be a mistake (where soon might mean any time this decade - at least). kre

Date: Thu, 16 Nov 2023 23:23:41 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <588e4312-2e83-4978-b236-642961ca41c3@cs.ucla.edu> | On 2023-11-16 21:04, Robert Elz via tz wrote: | > This does suggest though that for something like tzcode, which is used | > everywhere, requiring C99 anytime soon might be a mistake | | Not sure this particular example suggests that, as Alois merely needs to | compile with --std=gnu11 (or --std=gnu99 or -DPORT_TO_C89 or whatever). I wasn't suggesting a problem with the current distribution, that -D is a simple workaround (but expecting a gnuXX to work isn't - not everything is gcc), but in your earlier message you quotes the 2023a NEWS: The two new macros are transitional aids planned to be removed in a future version, when C99 or later will be required. and my point was just that that future version probably ought to be rather distant future, not next year sometime (or even the next few years after that). It might be worth adding a "common issues" file (with some rational name, not that) that people can look in, if things don't simply work first time, if for nothing else, to avoid needing to send queries to this list. kre

On Nov 17, 2023, at 11:20 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 2023-11-17 00:30, Robert Elz wrote:

...

It might be worth adding a "common issues" file

Yes, GNU Emacs does something like this, with its etc/PROBLEMS file (currently 4412 lines).

Currently TZDB puts this sort of thing in Makefile, which discusses the C89 issue along with dozens of similar porting issues. Evidently Makefile isn't always being read; this is not surprising as it has hundreds of lines of comments.

Not sure that a separate PROBLEMS file (which would also have hundreds of lines) would always be read either. To some extent we'll always be stuck getting email saying "this doesn't work for me" by people who haven't had time to read the relevant documentation, regardless of where that documentation is.

Perhaps the currently-52-lines-long (as of 2023c) README file could, in the section that talks about building the code, more vigorously point people either to the Makefile, as it does now, or to a separate document (which, if it contains just text, might be more readable than a Makefile comment), including explicitly saying "IF YOU'RE ON AN OLDER SYSTEM, SUCH AS RHEL 7/CENTOS whatever, YOU NEED TO READ THIS SECTION OF THIS DOCUMENT AND DO WHAT IT SAYS IF YOU WANT TO COMPILE THIS CODE".

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.

...

It might be worth adding a "common issues" file

Yes, GNU Emacs does something like this, with its etc/PROBLEMS file (currently 4412 lines).

Currently TZDB puts this sort of thing in Makefile, which discusses the C89 issue along with dozens of similar porting issues. Evidently Makefile isn't always being read; this is not surprising as it has hundreds of lines of comments.

Not sure that a separate PROBLEMS file (which would also have hundreds of lines) would always be read either. To some extent we'll always be stuck getting email saying "this doesn't work for me" by people who haven't had time to read the relevant documentation, regardless of where that documentation is.

For what it's worth, the Emacs etc/PROBLEMS file contains a long list of problems most of which nobody ever runs into nowadays, and hardly anybody reads the file.

I agree that a separate file pointing out PROBLEMS won't encourage anyone to read it. Guy's suggestion, elsewhere in this thread, to add a pointer to the Makefile in the README is a good idea. At least README has a fighting chance of being read ... the clue is in the name. :-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

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)

Paul Eggert wrote in <49c2b057-78da-477e-a6e1-2ef48fdc7b45@cs.ucla.edu>: |On 2023-11-18 15:01, Steffen Nurpmeso wrote: ... |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. ... |public domain. So tzcode makes do with awkward #ifdefs instead. (All I |can say for tzcode is, wait until 2053! :-) I would like to see this. Ciao, --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)