Document Number: AUSTIN/SD1

Title: ISSUES LIST

Revision Date: 2007-09-10

Source: Nick Stoughton/Andrew Josey

Change History

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)

  1. 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.

  2. 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.

  3. 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.

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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.

  10. 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

  11. ISSUE: How to deal with c99 defect reports and corrigenda; CX shade? Revision History?

    Resolved: TC1 will be incorporated in the standard, and shown only in the change history

  12. ISSUE: How to deal with shading for NaN. CX? XSI? Neither?

    Resolved; use MX shading for Math Extensions.

  13. 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.

  14. ISSUE: It is extremely unfortunate that ISO cannot manage to publish this standard as a single part without editorial change.

    Resolved 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.

  15. 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.

    Resolved; see Austin/382 which will be merged into D4R.

  16. 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.