[tz] Question about bug seen in OpenBSD and FreeBSD related to tzname
deepbluemistake at gmail.com
Sat Nov 23 06:27:29 UTC 2019
On Fri, Nov 22, 2019 at 9:30 PM Paul Eggert <eggert at cs.ucla.edu> wrote:
> What happens if you compile with -DHAVE_POSIX_DECLS=0? Arguably it
> should be set that way if FreeBSD does not declare the POSIX-required
> 'daylight' and 'timezone'.
With CFLAGS set to -DHAVE_POSIX_DECLS=0 alone, things compile and date
With CFLAGS set to '-DHAVE_POSIX_DECLS=0 -DUSG_COMPAT=1' the
compilation fails, albeit in a different way from with -DUSG_COMPAT=1
alone. Should I send both sorts of failures as text files?
> I see now that POSIX marks 'daylight' and 'timezone' with "XSI", meaning
> it's optional and present only if the X/Open Systems Interfaces option
> is supported, so perhaps tzcode should have a different macro for
> identifiers that are XSI rather than core POSIX.
Correct. The standard is separated into core POSIX, and POSIX+XSI
(known combined as SUS, UNIX, X/Open, and a bunch of other names)
The read-only (or intended to be read-only in your C program, and set
by the implementation, i.e. the OS) C macros are:
The macros intended to be set within a C program's source are:
In all these cases, if a XOPEN macro is set to something, you can
already assume a POSIX value too, since POSIX is a subset of XOPEN,
and XOPEN a superset of POSIX.
Hence, daylight and timezone might be considered XSI-required rather
than POSIX-required, when using those words specifically.
A quick grep shows tzcode does already uses _POSIX_VERSION and _XOPEN_VERSION
(I wonder if USG_COMPAT could be replaced entirely by POSIX and XOPEN
macros, but I'll have to look more deeply into that tonight before
saying what I think about that)
As a historical note, I think more XSI extensions to POSIX are
SystemV-biased than BSD-biased, with a lot of them coming from the
SVID. (though there are a couple BSD-biased XSI extensions, too)
That's just a note and not a judgment or anything. uwu
More information about the tz