[tz] USG_COMPAT and POSIX and XOPEN macros

Andras Farkas deepbluemistake at gmail.com
Sun Nov 24 06:35:00 UTC 2019


On Sat, Nov 23, 2019 at 7:37 PM Paul Eggert <eggert at 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?


More information about the tz mailing list