PASC Interpretation Request: ---------------------------- From: Geoff Clare Date: 2006 May 4 ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): AEP:POSIX(R) Realtime and Embedded Application Support: IEEE Std 1003.13-2003 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 6.1.2-4, 7.1.2-4, 8.1.2-4, 9.1.2-4 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): POSIX.13-2003 is intended to define four profiles of POSIX.1-2001 but it does not obey the POSIX.1-2001 subprofiling rules. Specifically, it places additional requirements on implementations that are of nature that the POSIX.1-2001 subprofiling rules disallow. These requirements are, briefly: 6.1.2: _POSIX_AEP_REALTIME_MINIMAL definition in 6.1.3: _POSIX_AEP_REALTIME_LANG_C99 and _POSIX_AEP_REALTIME_LANG_Ada95 definitions in 6.1.4: requirements on symbol visibility when the FTM (feature test macro) _POSIX_AEP_RT_MINIMAL_C_SOURCE is defined by applications 7.1.2: _POSIX_AEP_REALTIME_CONTROLLER definition in 7.1.3: _POSIX_AEP_REALTIME_LANG_C99 and _POSIX_AEP_REALTIME_LANG_Ada95 definitions in 7.1.4: requirements on symbol visibility when the FTM _POSIX_AEP_RT_CONTROLLER_C_SOURCE is defined by applications 8.1.2: _POSIX_AEP_REALTIME_DEDICATED definition in 8.1.3: _POSIX_AEP_REALTIME_LANG_C99 and _POSIX_AEP_REALTIME_LANG_Ada95 definitions in 8.1.4: requirements on symbol visibility when the FTM _POSIX_AEP_RT_DEDICATED_C_SOURCE is defined by applications 9.1.2: _POSIX_AEP_REALTIME_MULTI definition in 9.1.3: _POSIX_AEP_REALTIME_LANG_C99 and _POSIX_AEP_REALTIME_LANG_Ada95 definitions in 9.1.4: requirements on symbol visibility when the FTM _POSIX_AEP_RT_MULTI_C_SOURCE is defined by applications The POSIX.1-2001 subprofiling rules are stated in XBD6 section 2.1.5.1 "Subprofiling Considerations". The relevant part is: "The following additional rules shall apply to all profiles of IEEE Std 1003.1-2001: * Any application that conforms to that profile shall also conform to IEEE Std 1003.1-2001 (that is, a profile shall not require restricted, altered, or extended behaviors of an implementation of IEEE Std 1003.1-2001). * Profiles are permitted to add additional requirements to the limits defined in and , subject to the following: For the limits in and : o If the limit is specified as having a fixed value, it shall not be changed by a profile. o If a limit is specified as having a minimum or maximum acceptable value, it may be changed by a profile as follows: + A profile may increase a minimum acceptable value, but shall not make a minimum acceptable value smaller. + A profile may reduce a maximum acceptable value, but shall not make a maximum acceptable value larger. * A profile shall not change a limit specified as having a minimum or maximum value into a limit specified as having a fixed value. * A profile shall not create new limits. * Any implementation that conforms to IEEE Std 1003.1-2001 (including all options and extended limits required by the profile) shall also conform to that profile." It is the first and last items in this list that POSIX.13 does not obey. A related issue is the requirement on applications to define FTMs (feature test macros) such as _POSIX_AEP_RT_MULTI_C_SOURCE. Since the POSIX.1 subprofiling rules mean that profiles cannot require implementations to recognise additional FTMs, there would appear to be little point in requiring applications to define them. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): There would appear to be two choices: A) Change POSIX.13 so that it obeys the POSIX.1 subprofiling rules, and eliminate the bogus FTM requirement, by removing all mention of symbols beginning _POSIX_AEP_. B) Try and persuade the Austin Group to alter the subprofiling rules in POSIX.1. I doubt very much if this would succeed, since one of the basic principles on which those rules are based is that a conforming POSIX.1 system can conform to any profile just by supporting the POSIX options that the profile mandates and meeting the more restrictive requirements on limit values that the profile makes. POSIX.13 currently violates this principle, not just the letter of the rules. ------------------------------------------------------------------------ Interpretation: ---------------- It is not clear on this issue that the POSIX.1 subprofiling rules prohibit a POSIX.13 implementation making these symbols visible, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." Rationale: ------------- There appears to be a conflict between the POSIX.1 subprofiling rules and the POSIX.13 requirements for additional symbols to be defined in and for implementations to alter the visibility of symbols in headers when applications define additional FTMs. This interpretation follows the guideline that where there is a recognized defect that interpretations must favour a looser conformance requirement rather than a more restrictive one. Notes to editors for a future revision (not part of the interpretation): ----------------------------------------------------------------------- We were unable to reach consensus on this issue. It is suggested that a followup interpretation be posted to the 1003.1 committee. The 1003.1 interpretation reference is 1003.1-2001 #183. Forwarded to interpretations group: Aug 15 2006 Proposed resolution: Thu Oct 19 17:19:48 BST 2006 Final resolution: Mon Jun 2 17:41:04 BST 2008