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.