USG_COMPAT and POSIX and XOPEN macros
I've noticed that USG_COMPAT shouldn't be replaced by XOPEN macros since it's clear USG_COMPAT is meant to be something users of tzcode can toggle. However, if someone has an application where they set _XOPEN_SOURCE to 700 or another value, I wonder if there should be something equivalent to the following in private.h #ifndef USG_COMPAT # ifndef _XOPEN_VERSION # define USG_COMPAT 0 # else # define USG_COMPAT 1 # endif #endif But using _XOPEN_SOURCE instead. (while also retaining the block of code using _XOPEN_VERSION too. I think in cases where both macros are involved, priority should be given to _XOPEN_SOURCE since it's explicitly what an application programmer has asked for) Right now, the code only reads _XOPEN_VERSION (from the OS) but not _XOPEN_SOURCE (from the application) This possibly could also apply to how only _POSIX_VERSION is currently used, but not _POSIX_C_SOURCE (nor the obsolete _POSIX_SOURCE, but that's been superseded for a long time now) This topic originates in this thread: http://mm.icann.org/pipermail/tz/2019-November/028596.html http://mm.icann.org/pipermail/tz/2019-November/thread.html
On 2019-11-23 01:33, Andras Farkas wrote:
I've noticed that USG_COMPAT shouldn't be replaced by XOPEN macros since it's clear USG_COMPAT is meant to be something users of tzcode can toggle.
However, if someone has an application where they set _XOPEN_SOURCE to 700 or another value, I wonder if there should be something equivalent to the following in private.h #ifndef USG_COMPAT # ifndef _XOPEN_VERSION # define USG_COMPAT 0 # else # define USG_COMPAT 1 # endif #endif But using _XOPEN_SOURCE instead. (while also retaining the block of code using _XOPEN_VERSION too. I think in cases where both macros are involved, priority should be given to _XOPEN_SOURCE since it's explicitly what an application programmer has asked for)
Right now, the code only reads _XOPEN_VERSION (from the OS) but not _XOPEN_SOURCE (from the application)
This possibly could also apply to how only _POSIX_VERSION is currently used, but not _POSIX_C_SOURCE (nor the obsolete _POSIX_SOURCE, but that's been superseded for a long time now)
This topic originates in this thread: http://mm.icann.org/pipermail/tz/2019-November/028596.html http://mm.icann.org/pipermail/tz/2019-November/thread.html
For guidance, you may want to check and compare how feature test macros are used on your system (and others) in time.h, and other library headers with XSI extensions. You may want to consider any implications of _XOPEN_SOURCE_EXTENDED being defined. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On 11/23/19 12:33 AM, Andras Farkas wrote:
But using _XOPEN_SOURCE instead.
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 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.
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?
On 11/23/19 10:35 PM, Andras Farkas wrote:
so I can actually test tzcode like this, should I patch the tz github repo, or the 2019c tarball?
I forgot to push that patch to GitHub. I just now pushed it, so you should be able to use GitHub master now, without having to apply the patch.
On Fri, Nov 29, 2019 at 2:55 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 11/23/19 10:35 PM, Andras Farkas wrote:
so I can actually test tzcode like this, should I patch the tz github repo, or the 2019c tarball? I forgot to push that patch to GitHub. I just now pushed it, so you should be able to use GitHub master now, without having to apply the patch. Thanks! However, on FreeBSD (thinking back to the connections between this thread and another thread) compilation fails with: CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0 I suggest something like the attached diff, which makes compilation succeed, while fitting in line with what the internal macros are currently doing.
On 11/30/19 7:31 AM, Andras Farkas wrote:
On Fri, Nov 29, 2019 at 2:55 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
However, on FreeBSD (thinking back to the connections between this thread and another thread) compilation fails with: CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0 I suggest something like the attached diff, which makes compilation succeed, while fitting in line with what the internal macros are currently doing.
Thanks for the bug report. Unfortunately that patch would refer to TZ_TIME_T before it's defined, and TZ_TIME_T's definition depends on time.h which must be included after the first part of the patch. So I installed the attached patch, which does not refer to TZ_TIME_H and which I hope fixes the problem in a simpler way.
On Mon, Dec 2, 2019 at 9:28 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks for the bug report. Unfortunately that patch would refer to TZ_TIME_T before it's defined, and TZ_TIME_T's definition depends on time.h which must be included after the first part of the patch. So I Oh! Good point. installed the attached patch, which does not refer to TZ_TIME_H and which I hope fixes the problem in a simpler way. This looks good and runs perfectly. Both CFLAGS= -DUSG_COMPAT=2 CFLAGS= -DUSG_COMPAT=2 -DHAVE_POSIX_DECLS=0 work A-OK now! Thanks! :D
participants (3)
-
Andras Farkas -
Brian Inglis -
Paul Eggert