On Sat, Nov 23, 2019 at 7:37 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
This code is part of the implementation, not part of the application, so it shouldn't be fooling with feature-test macros. But I take your point that the Ah, I didn't mean setting any of those! tzcode wouldn't set any of those, but would read those. This is what I've seen implementations do, from my reading and my experience. For example, in both FreeBSD and OpenBSD (from actual grepping and reading /usr/include/ headers) and from what I understand of GNU/Linux man pages: C headers read from the _SOURCE macros (rather than the _VERSION macros) to decide what to hide or expose to a program. (they may set internal macros too, of course, based on the _SOURCE macros they read) This is also my experience in programming C applications (well, a specific one in particular). In a program I was working on, the only way to ask for strptime() on a GNU/Linux system was to set _XOPEN_SOURCE in the application. i.e. the implementation was reading the _XOPEN_SOURCE macro (not the _XOPEN_VERSION macro) to decide whether to expose or hide strptime() on GNU/Linux. Our CI system had shown that strptime(), which we had recently begun using from the OS rather than using our own handmade equivalent, was exposed by default on FreeBSD but that on GNU/Linux we were getting a warning. GNU/Linux man pages clarified that strptime() wasn't exposed by default, and that glibc was reading _XOPEN_SOURCE The GNU/Linux man page involved confirms this: https://linux.die.net/man/3/strptime http://man7.org/linux/man-pages/man3/strptime.3.html
All I mean is that both sets of macros have some value, but that the _SOURCE macros are what applications are setting when seeking different features from the implementation/OS. (hence, possibly that they request more features from tzcode than they'd normally get) The _VERSION macros are a claim of what the OS does and doesn't support.
code should more carefully distinguish the features it supports from the features the underlying C library supports. So I installed the attached proposed patch to try to make this clearer and to support your use case. This patch reads A-OK to me. *thumbs-up* But, so I can actually test tzcode like this, should I patch the tz github repo, or the 2019c tarball?