[tz] USG_COMPAT and POSIX and XOPEN macros

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Sat Nov 23 15:27:51 UTC 2019


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.


More information about the tz mailing list