tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Host requirements to build the Tools binaries
Before I get into this, my general take on the issue is that we
should just remove the strptime() call from date.c ... it is only
being used to parse YYYYmmDD date specifications, and if we cannot
simply open code that, we have bigger problems than this. This is
used only in the tools version of date(1) - so we don't need to be
concerned about /bin/date growing a whole bunch of crap.
Never mind, that's too easy, so....
Date: Thu, 15 Aug 2024 18:59:37 +0900
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Message-ID: <240815185937.M0116007%mirage.ceres.dti.ne.jp@localhost>
| On Linux (actually glibc2), _XOPEN_SOURCE expand declarations to add
| XPG4 functions etc.
| On NetBSD (and FreeBSD and OpenBSD), _XOPEN_SOURCE restricts declarations
| to disallow NetBSD or GNU extensions.
I think that both are correct in their own ways. The Linux behaviour
is permitted, though not required, and the BSD behaviour allows applications
to be strictly XSI conforming if they desire.
| Then several packages require extra -D_NETBSD_SOURCE definitions to
That's an additional feature request which allows applications which
would otherwise be strictly conforming to gain access to additional
functionality provided by the implementation.
Defining _XOPEN_SOURCE is required of an application to be a strictly
conforming XSI application, which imposes a whole set of rules upon it
about what it is, or isn't, allowed to do. It also makes the application
portable to more environments.
There is no actual requirement to define _XOPEN_SOURCE to obtain access
to XSI additions to the standard, however there's no requirement upon
an implementation to support the XSI extensions, and an implementation can
decide to do so only if the application says it wants them (by defining
_XOPEN_SOURCE) if it so desires (that seems to be what linux is doing).
However, applications should not use XSI additions unless _XOPEN_UNIX
is defined (by the implementation). Getting that to appear may mean
defining _XOPEN_SOURCE (before including any standard headers, which need
to be included before the application can expect the _XOPEN_UNIX symbol
to appear - any standard header should do for that.)
I don't believe that NetBSD defines _XOPEN_UNIX and it should (nor
_XOPEN_VERSION which should accompany _XOPEN_UNIX if the latter is defined
to anything other than -1 ... what value _XOPEN_VERSION should be defined
to be depends upon which version of the standard we actually implement --
But that is probably SUS 5 (SUSV) and if so, 800 is the correct value - but
no, I have no idea where "800" comes from.)
Similarly, date(1) (as a tool - ie: super portable, as distinct from
the NetBSD application) should not be using strptime() unless _XOPEN_UNIX
is found to be defined. Simply defining _XOPEN_SOURCE cannot be
expected to make that happen - either the implementation has the XSI
extensions, or it does not. If it doesn't, defining _XOPEN_SOURCE
cannot make them appear by magic.
However, to be posix conforming, applications need to define either
_POSIX_C_SOURCE or _XOPEN_SOURCE (or both) before including any of
the standard's headers. If that isn't done, which is I suspect quite
common for NetBSD code, what the C compiler actually makes available is
undefined (by the standard) - ie: implementations can do whatever they
like, though POSIX encourages such implementations to act as if they
application is compiling in a strictly C conforming environment, which I
suspect means no strptime(3).).
What that says, in effect, (and it is kind of obvious anyway) is that
there is no requirement that any particular application conform to anything.
Nothing stops it working, and being useful, without some conformance
claim .. but it might not work elsewhere.
*** You can stop reading now if you like, what follows is what I
*** extracted from the standard to reach the conclusions above.
For references for all of this I am using the latest (2024) posix
standard, which I suspect is not on the web yet (but it is coming I think).
However, given the section numbers & headings below, you can probably
locate the equivalent in the current (Issue 7 TC 2 (2018)) version that
is on the web (which has been referenced earlier in this thread).
The page numbers mentioned below are relevant only if you have the PDF
version of the 2024 standard, otherwise simply ignore them.
This all starts in XBD 1 (Introduction) (XBD is "Base Definitons")
1.1 Scope [mostly not relevant here]
1.2 Word Usage [defines "shall" ... generally obvious]
1.3 Conformance
Conformance requirements for POSIX.1-2024 are defined in
Chapter 2 (on page 15).
1.4 Normative References [not relevant here]
1.5 Change History [not relevant here]
1.6 Terminology [not important here, defines things like "unspecified"
and "undefined" (quite a few more)]
1.7 Definitions and Concepts [just a pointer to other sections, not
relevant here]
1.8 Portability
Some of the utilities in the Shell and Utilities volume of
POSIX.1-2024 and functions in the System Interfaces volume of
POSIX.1-2024 describe functionality that might not be fully portable
to systems meeting the requirements for POSIX conformance (see
Chapter 2, on page 15).
Where optional, enhanced, or reduced functionality is specified,
the text is shaded and a code in the margin identifies the nature
of the option, extension, or warning (see Section 1.8.1). For
maximum portability, an application should avoid such functionality.
[There is more, about output formats from utilities, particularly ones
which don't produce text files, but none of that is relevant here.]
1.8.1 Codes
The codes and their meanings are as follows. See also Section 1.8.2
(on page 12).
There follows a long list of different codes, only one of which is
relevant here:
XSI X/Open System Interfaces
The functionality described is part of the X/Open Systems
Interfaces option. Functionality marked XSI is an extension
to the ISO C standard. Application developers may confidently
make use of such extensions on all systems supporting the X/Open
System Interfaces option.
If an entire SYNOPSIS section is shaded and marked XSI, all the
functionality described in that reference page is an extension.
See Section 2.1.4 (on page 19).
[Note there is nothing there about what kind of application, in terms of
its conformance claims (see below) can "confidently make use" of those
extensions, only what happens when the implementation supports them.]
1.8.2 Margin Code Notation
[This deals with things like how the standard deals with things
which depend upon 2 (or more) options, etc, and most isn't relevant
here. But...]
Large Sections Dependent on an Option
Where large sections of text are dependent on support for an option,
a lead-in text block is provided and shaded accordingly; for example:
XSI This section describes extensions to support interprocess communication.
The functionality described in this section shall be provided on
implementations that support the XSI option (and the rest of this
section is not further shaded).
[That preceding paragraph is "shaded" - which just means printed with a
grey, rather than white, background. In general when there's a margin code
the relevant text (sometimes just a couple of words, sometimes entire
paragraphs) will be shaded - I won't say where that happens explicitly.]
And then we get to XBD 2 (Conformance):
2.1.1 Requirements
A conforming implementation shall meet all of the following criteria:
1. The system shall support all utilities, functions, and
facilities defined within POSIX.1-2024 that are required for
POSIX conformance (see Section 2.1.3, on page 17). These
interfaces shall support the functional behaviordescribed herein.
2. The system may support the X/Open System Interfaces (XSI) option
as described in Section 2.1.4 (on page 19).
Then 3. allows implementations to support other POSIX defined options, and
4. allows non-standard extensions, and what that means. None of that is
relevant here.
2.1.2 is all about required documentation (required of the implementation
to conform to the standard) and isn't relevant here.
2.1.3 is "POSIX Conformance" and says what the implementation must do for
that - also not relevant here.
2.1.4 is "XSI shaded" (which means it only applies if the implementation
implements the XSI extension).
2.1.4 XSI Conformance
XSI This section describes the criteria for implementations providing
conformance to the X/Open System Interfaces (XSI) option (see
Section 3.424, on page 93). The functionality described in this
section shall be provided on implementations that support the XSI
option (and the rest of this section is not further shaded).
POSIX.1-2024 describes utilities, functions, and facilities offered
to application programs by the X/Open System Interfaces (XSI) option.
An XSI-conforming implementation shall meet the criteria for POSIX
conformance and the following requirements listed in this section.
XSI-conforming implementations shall set the symbolic constant
_XOPEN_UNIX to a value other than -1 and shall set the symbolic
constant _XOPEN_VERSION to the value 800.
(Specific values like that relate to the specific version of the standard
being conformed with - NetBSD is certainly not yet ready to conform with
POSIX-2024, or anything really close to it, but the same general principles
apply to earlier versions of the standard - just different values apply)
2.1.4.1 XSI System Interfaces
The following requirements apply to the system interfaces when
the XSI option is supported:
� The system shall support all the functions and headers defined
in POSIX.1-2024 as part of the XSI option denoted by the XSI
marking in the SYNOPSIS section, and any extensions marked
with the XSI option marking (see Section 1.8.1, on page 7)
within the text.
There's a whole bunch more requirements on the implementation, but none of
them are relevant here.
There's more in 2.1 about other options, and stuff - nothing relevant.
2.2 Application Conformance
For the purposes of POSIX.1-2024, the application conformance
requirements given in this section apply.
All applications claiming conformance to POSIX.1-2024 shall use
only language-dependent services for the C programming language
described in Section 2.3 (on page 29), shall use only the
utilities and facilities defined in the Shell and Utilities
volume of POSIX.1-2024, and shall fall within one of the
following categories.
2.2.1 Strictly Conforming POSIX Application
A Strictly Conforming POSIX Application is an application that
requires only the facilitiesdescribed in POSIX.1-2024. Such an
application:
Then there's a bunch of rules, most of which are not relevant here, but:
5. Is required to tolerate and permitted to adapt to the
presence or absence of optional facilities whose availability
is indicated by Section 2.1.3 (on page 17)
8. For the C programming language, shall define _POSIX_C_SOURCE
to be 202405L before any header is included
2.2.2 Conforming POSIX Application
2.2.2.1 ISO/IEC Conforming POSIX Application
[not relevant here]
2.2.2.2 <National Body> Conforming POSIX Application
[not relevant here]
2.2.3 Conforming POSIX Application Using Extensions
[not relevant here]
2.2.4 Strictly Conforming XSI Application
A Strictly Conforming XSI Application is an application that requires
only the facilities described in POSIX.1-2024. Such an application:
Again, a whole set of rules, including:
8. For the C programming language, shall define _XOPEN_SOURCE
to be 800 before any header is included
Within POSIX.1-2024, any restrictions placed upon a Conforming
POSIX Application shall restrict a Strictly Conforming XSI Application.
2.2.5 Conforming XSI Application Using Extensions
[not relevant here]
Note that there is no requirement that any application be any of those,
the rules apply only if the application desires to call itself one of
those types of applications.
Next we get to XSH (System Interfaces) [ie: functions\
section 2 "General Information".
The following section numbers are all XSH (until stated otherwise), those
earlier have all been XBD (XBD, XSH, XCU and XRAT are the 4 volumes that
make up the POSIX standard).
2.2 The Compilation Environment
2.2.1 POSIX.1 Symbols
Certain symbols in this volume of POSIX.1-2024 are defined in headers
(see XBD Chapter 14, on page 221). Some of those headers could also
define symbols other than those defined by POSIX.1-2024, potentially
conflicting with symbols used by the application. Also, POSIX.1-2024
defines symbols that are not permitted by other standards to appear
in those headers without some control on the visibility of those symbols.
Symbols called ``feature test macros'' are used to control the
visibility of symbols that might be included in a header.
Implementations, future versions of this standard, and other standards
may define additional feature test macros.
In the compilation of an application that #defines a feature test
macro specified by POSIX.1-2024, no header defined by POSIX.1-2024
shall be included prior to the definition of the feature test macro.
This restriction also applies to any implementation-provided header in
which these feature test macros are used. If the definition of the
macro does not precede the #include, the result is undefined.
Feature test macros shall begin with the <underscore> character ('_').
2.2.1.1 The _POSIX_C_SOURCE Feature Test Macro
A POSIX-conforming application shall ensure that the feature test
macro _POSIX_C_SOURCE is defined before inclusion of any header.
When an application includes a header described by POSIX.1-2024,
and when this feature test macro is defined to have the value 202405L:
1. All symbols required by POSIX.1-2024 to appear when the
header is included shall be made visible.
2. Symbols that are explicitly permitted, but not required,
by POSIX.1-2024 to appear in that header (including those
in reserved name spaces) may be made visible.
3. Additional symbols not required or explicitly permitted by
POSIX.1-2024 to be in that header shall not be made visible,
except when enabled by another feature test macro.
Identifiers in POSIX.1-2024 may only be undefined using the #undef
directive as described in Section 2.1 (on page 495) or Section
2.2.2 (on page 498). These #undef directives shall follow all
#include directives of any header in POSIX.1-2024.
Note: The POSIX.1-1990 standard specified a macro called
_POSIX_SOURCE. This has been superseded by _POSIX_C_SOURCE.
2.2.1.2 The _XOPEN_SOURCE Feature Test Macro
XSI An XSI-conforming application shall ensure that the feature test
macro _XOPEN_SOURCE is defined with the value 800 before inclusion
of any header. This is needed to enable the functionality described
in Section 2.2.1.1 (on page 496) and to ensure that the XSI option is
enabled.
Since this volume of POSIX.1-2024 is aligned with the ISO C standard,
and since all functionality enabled by _POSIX_C_SOURCE set equal to
202405L is enabled by _XOPEN_SOURCE set equal to 800, there should
be no need to define _POSIX_C_SOURCE if _XOPEN_SOURCE is so defined.
Therefore, if _XOPEN_SOURCE is set equal to 800 and _POSIX_C_SOURCE
is set equal to 202405L, the behavior is the same as if only
_XOPEN_SOURCE is defined and set equal to 800. However, should
_POSIX_C_SOURCE be set to a value greater than 202405L, the behavior
is unspecified.
If _XOPEN_SOURCE is defined with the value 800 and _POSIX_C_SOURCE
is undefined before inclusion of any header, then the header may
define the _POSIX_C_SOURCE macro with the value 202405L.
2.2.1.3 [not relevant here]
2.2.2 The Name Space
All identifiers in this volume of POSIX.1-2024, except environ, are
defined in at least one of the headers, as shown in XBD Chapter 14
(on page 221). When
XSI _XOPEN_SOURCE or
_POSIX_C_SOURCE is defined,
each header defines or declares some identifiers, potentially
conflicting with identifiers used by the application. The set of
identifiers visible to the application consists of precisely those
identifiers from the header pages of the included headers,
as well as additional identifiers reserved for the implementation.
In addition, some headers may make visible identifiers from other
headers as indicated on the relevant header pages.
There is more, but it isn't relevant here.
I don't believe there's anything more of general relevance (not specifically
about the issue under discussion) until we get to XCU (Commands and Utilities)
section 3 (descriptions of every utility that exists, other than sh special
builtin utilities, which are in XCU 2.15 - XCU 2 is a description of the shell,
as distinct from the "sh" command, which is in XCU 3 like everything else).
The XCU 3 page for "c17" (the only standards defined C compiler invoking
utility - in this version of the standard) includes this text in its
APPLICATION USAGE section, which is not normative (not part of the standard,
just additional guidance as to what the standard means).
Since this standard requires that conforming applications define
either _POSIX_C_SOURCE or _XOPEN_SOURCE before inclusion of any header
(see XSH Section 2.2.1, on page 496), if c17 is used to compile source
code that includes a header without defining one of these feature test
macros in the required manner, the behavior of c17 itself and the
results of using any files it generates are undefined. When c17 is
used this way, implementations are encouraged to make visible in
headers from the ISO C standard only the symbols that are allowed by
that standard, and otherwise to behave the same as if _POSIX_C_SOURCE
or _XOPEN_SOURCE had been defined, but portable applications cannot
rely on this.
And lastly, we get to XRAT (Rationale, History, ...) none of which is
normative, but which says in XRAT B 2.2.1 (B 2 is "General Information",
B 2.2 is "The Compilation Environment", B 2.2.1 is "POSIX.1 Symbols"):
The _XOPEN_SOURCE Feature Test Macro
The feature test macro _XOPEN_SOURCE is provided as the announcement
mechanism for the application that it requires functionality from the
Single UNIX Specification. _XOPEN_SOURCE must be defined to the value
800 before the inclusion of any header to enable the functionality in
the Single UNIX Specification Version 5. Its definition subsumes the
use of _POSIX_C_SOURCE.
An extract of code from a conforming application, that appears before
any #include statements, is given below:
#define _XOPEN_SOURCE 800 /* Single UNIX Specification, Version 5 */
#include ...
Note that the definition of _XOPEN_SOURCE with the value 800 makes
the definition of _POSIX_C_SOURCE redundant and it can safely be omitted.
And for some specific information, in XBD 14 ("Headers") in the page for
<time.h> the specification for strptime() is XSI shaded (that I think
everyone getting this far knew already).
Similarly the XSH 3 ("System Interfaces") page for strptime() is
entirely XSI shaded (as printed, just the SYNOPSIS section is, but when
that's done, it means the entire thing.)
Those mean that strptime() is not available unless the XSI option has
been provided by the implementation, and it is an option, so it cannot
be guaranteed (but is more likely - and that's all it is - if the
_XOPEN_SOURCE feature macro was defined before any system includes were
included).
And lastly, and while not currently relevant to this, it could be if
we wanted,. <sys/cdefs.h> is not a standard include file - there's no
requirement that feature macros be defined before it has been included,
and no prohibition on it from defining some if it so desired.
kre
Home |
Main Index |
Thread Index |
Old Index