Document Number: AUSTIN/SD1
Title: ISSUES LIST
Revision Date: 2007-09-10
Source: Nick Stoughton/Andrew Josey
March 4th - Document Created after Menlo Park Meeting (Austin/2)
July 22 - Updated after Montreal Meeting (Austin/3)
May 19 2000 - Updated after Reading Meeting (Austin/M5)
October 13 2000 - Updated after Austin Meeting (Austin/M6)
May 9 2002 - Updated after Austin Meeting (Austin/M9)
Sep 15 2006 - Updated after Austin Meeting (Austin/M12)
Sep 10 2007 - Updated after Austin Meeting (Austin/M14)
ISSUE: (Austin/M2) if SGML is required,
this may mean that the SUD rather SUS is used as a base doc, which is less
familiar to most people in the WG. Should we mandate that the specification is
developed in SGML?
Resolved; SGML is not a
requirement for the base doc, but is left entirely to the editor. There will
be an SGML version generated at the end.
ISSUE: (Austin/M2) how to handle
overlapping functions between ISO-C and the joint standard. Proposal: document
all functions but clearly identify which words give way to C standard
RESOLVED (Austin/M7): The C committee are not so unhappy about our current approach (Keld's words).
We will continue to use CX shading.
ISSUE: (Austin/M2) how to handle UNIX
extended functionality. AUSTIN/18 identifies a large number of functions not
currently in POSIX (and marked as EX in XSH/XCU) that may require to be
optional, or new mandatory. Some may become new legacy/obsolete.
Proposal: The use of XSI shading will denote UNIX extended functionality.
RESOLVED (Austin/M7). All agreed with the above proposal.
ISSUE: (Austin/M3) come up with consistent naming conventions for the documents
to use throughout, and a name to refer to the set.
Resolved; volume titles have been agreed and will be used consistently
ISSUE: (Austin/M3) the index - what to do with cross volume references, if a common index to all volumes is required. (see also XBD D1 ERN 136).
Resolved; volume titles have been agreed, and will be used consistently
ISSUE: (Austin/M3) what version of C is this standard to be based on.
If it is c99, should XCU c89 utility refer to the c99 compiler, or
will there be a new utility? If c99, then how to get new XSH functions
included, how to change footprint of existing functions etc.
Resolved; use c99
ISSUE: (Austin/M3) (see XCU D1 ERN 157) If c89 is kept, but we align
with c99 XBS5 is not an appropriate identifier, since it refers to a
different version. (see also getconf)
Resolved; c89 will not be kept. XBS5 -> POSIX_V6
ISSUE: (Austin/M3) (see XCU D1 ERN 195) cannot be resolved until c9x
issues are closed. Since c9x strftime and POSIX locale definition of %c
and %p differ, we cannot simply refer to strftime at this point.
Resolved; this has been fixed in ISO/IEC 9899-1999
ISSUE: (Austin/M3) need to produce a conformance statement that encompasses
the entire document set, i.e. what POSIX.1 conformance is when it includes
both System Interfaces and Shell and Utilities.
Resolved; a single conformance statement in XBD volume exists
Conformance is to the entire standard, and not to any volume. Shell and
utilities conformance is not an option.
ISSUE: (Austin/M3) what to do about 1003.1n? Should it be balloted, or should it die and the PAR for this project be modified to include that work? An
alternative would be for the material in 1003.1n to be submitted as a
series of interpretations against the existing 1003.1.
Resolved; these changes have now been incorporated as interpretation derived aardvark in D3
ISSUE: How to deal with c99 defect reports and corrigenda; CX shade?
Resolved: TC1 will be incorporated in the standard, and shown only in the change history
ISSUE: How to deal with shading for NaN. CX? XSI? Neither?
Resolved; use MX shading for Math Extensions.
ISSUE: Large files in ftw() ... ftw should walk the entire tree, but it
also should fail if it encounters a large file with a 32 bit off_t
(EOVERFLOW in stat).
Resolved: Add EOVERFLOW as a shall fail error to both ftw and nftw.
ISSUE: It is extremely unfortunate that ISO cannot manage to publish this
standard as a single part without editorial change.
we will accept their proposal to publish as four parts, with the proviso
that it should be distributed on a single CD and sold as a single standard.
Note that for the 2008 revision the standard has been reorganized to
a single part and this is thus no longer an issue.
ISSUE: (Austin/M12) The standard needs a way to open a directory for searching. While the *at functions which are being added to SUSv4 were being discussed, a proposal was made on a way to open directories for searching; initial attempts to formulate this proposal showed that further thought was necessary, and it was not suitable for standardization at that time.
see Austin/382 which will be merged into D4R.
ISSUE: XBDd1r ERN 1, what is the standard called within the text.
At the moment it is IEEE Std 1003.1-200x. Should this be ISO/IEC 9945?
Could it be simply POSIX.1 or this standard?
Resolved; the standard is called POSIX.1-200x.