NOTICE: This is an unapproved draft, it is a work in progress, subject to change. Updated 31 Jan 2003, add ERN 12 Updated 7 Feb 2003, after telcon Update 19 Feb 2003, add new inbound rdvk 12-16 Updated 21 Feb 2003, add OPEN tags for searching Updated 28 Feb 2003, after telcon Updated 14 Mar 2003, after telecon Updated 31 Mar 2003, new rdvk added Updated 11 April 2003, after telcon Updated 23 April 2003, add new rdvk Updated 7 May 2003, add new rdvk Updated 21 May 2003, add new rdvk , also mark items as TC candidates Updated 28 May 2003, updated after meeting Updated 20 June 2003, add new rdvk Updated 14 July 2003, add new rdvk Updated 18 July 2003, update after meeting Updated 31 July 2003, update comment in ERN 15 Updated 13 Aug 2003, add new erns Updated 15 Aug 2003, after telco Updated 29 Aug 2003, after telco Updated 3 Sep 2003, after telco Updated 12 Sep 2003, after telco Updated 26 Sep 2003, after telco _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 pere@hungry.com Defect in XBD setnetgrent()/innetgr() (rdvk# 10) {0} Sun, 1 Dec 2002 11:35:31 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Not appropriate for a defect report against the current spec. See the new work item guidelines in Austin/122 for how to progress this item. _____________________________________________________________________________ Page: 0 Line: 0 Section: setnetgrent()/innetgr() Problem: Defect code : 2. Omission Currently, several Unices include API to access netgroups. Netgroups is as far as I know the only way to refere to groups of machines in configuration files and access lists. The netgroups are normally access from NIS, but can also be accessed from local files or from LDAP. The normal API seem to be these functions: #include int getnetgrent(char **machinep, char **userp, char **domainp); int getnetgrent_r(char **machinep, char **userp, char **domainp, char *buffer, int buflen); int setnetgrent(const char *netgroupm); int endnetgrent(void); int innetgr(const char *netgroup, const char *machine, const char *user, const char *domain); Some Unices do not have a return value from setnetgrent() (AIX, FreeBSD), but this make it impossible to know the the difference between a non-existand netgroup and an empty netgroup. I've been unable to find any standard text referencing this API. This API also have some missing features. It is impossible to get a list of all netgroups, and it is impossible to do reverse lookup, finding out which netgroups a given host or user is a member of. Action: The austin group should standardize the netgroup access API, possibly extending it to allow access to the list of all netgroups, and also extend it to allow reverse lookups. _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 Erwin.Unruh@fujitsu-siemens.com Defect in XBD lround (rdvk# 8) {0} Tue, 12 Nov 2002 09:37:51 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change required. The current text is aligned with Annex F as shown by the MX shaded text, and ISO C DR 240 allows this (see notes from Fred T) C99 Defect Report (DR) 240 covers this. The main body of C99 (7.12.9.7) says range error, while Annex F (F.9.6.7 and F.9.6.5) says "invalid" (domain error). The result was to change 7.12.9.7 to allow for either range or domain error. The preferred error is domain error (so as match Annex F). So, no need to change XBD/XSH. _____________________________________________________________________________ Page: 0 Line: 0 Section: lround Problem: Defect code : 1. Error The function lround is described in http://www.opengroup.org/onlinepubs/007904975/functions/lround.html On Error it is specified that errno has to be set to EDOM. However, the C99 standard ISO/IEC 9899:1999 (E) specifies this as a range error, which would result in a value of ERANGE. So an implementation could not be conformant to both these standards. Action: Change the value of errno to ERANGE, if the result is not represantable. More specific: In the description of the function, replace all occurences of "domain error" with "range error" and replace "EDOM" with "ERANGE" _____________________________________________________________________________ OBJECTION Enhancement Request Number 3 drepper@redhat.com Defect in XBD Conformance (rdvk# 5) {ud-process-34} Tue, 22 Oct 2002 03:25:34 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 23 Line: 923 Section: Conformance Problem: Defect code : 1. Error Similarly to ud-process-3, the text describes the priority of an AIO request. [...] priority equal to the scheduling priority of the process minus aiocbp->aio_reqprio. It's the calling threads scheduling priority if pthread_attr_setschedparam is supported. Action: Change line 923 to: priority of the calling thread minus aiocbp->aio_reqprio. The implementation shall also document for _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 drepper@redhat.com Defect in XBD Definitions (rdvk# 4) {ud-vfork} Tue, 22 Oct 2002 03:36:43 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Accept and also make the same change on line 1622 _____________________________________________________________________________ Page: 46 Line: 1620 Section: Definitions Problem: Defect code : 2. Omission The list of functions which can create a child process currently is fork( ), posix_spawn( ), or posix_spawnp(). vfork() is missing. Action: Change the beginning of line 1620 to: A new process created (by fork(), vfork(), posix_spawn(), or posix_spawnp()) _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 David.Butenhof@hp.com Defect in XBD 3.297 (rdvk# 7) {drb.6.exit.def} Tue, 12 Nov 2002 13:09:04 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Replace item 1 (lines 2437 and 2438) as follows: 1. Normal termination occurs by a return from main(), when requested with the exit(), _exit(), or _Exit() functions; or when the last thread in the process terminates by returning from its start function, by calling the pthread_exit() function, or through cancellation. 2) Add "_Exit(), " to 2441: 2441 Note: The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume 2442 of IEEE Std 1003.1-2001. _____________________________________________________________________________ Page: 74 Line: 2437 Section: 3.297 Problem: Defect code : 2. Omission "Normal termination" is defined as: 1. Normal termination occurs by a return from main() or when requested with the exit() or _exit() functions. This is incorrect: it omits the C99 addition of _Exit(), and also the provision for process exit when the last thread terminates. Action: Replace item 1 (lines 2437 and 2438) as follows: 1. Normal termination occurs by a return from main(), when requested with the exit(), _exit(), or _Exit() functions; or when the last thread in the process terminates by returning from its start function, by calling the pthread_exit() function, or through cancellation. _____________________________________________________________________________ COMMENT Enhancement Request Number 6 terekhov@de.ibm.com Defect in XBD 3.297 Process Termination (rdvk# 9) {alt-3.297-2002-11-12} Tue, 12 Nov 2002 13:37:44 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_5 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 74 Line: 2438,2441 Section: 3.297 Problem: Defect code : 2. Omission The "3.297 Process Termination" definition doesn't mention the ``passive exit'' on termination of the last thread. Well, it also doesn't mention the _Exit() function. It should be updated. Action: A) Replace 2437 1. Normal termination occurs by a return from main() or when requested with the exit() or 2438 _exit() functions. with 2437 1. Normal termination occurs by a return from main() or when requested with the exit() or 2438 _exit() or _Exit() functions or on the last thread termination when the behavior is as if the implementation called exit() with a zero argument at thread termination time. (or something like that) B) Add "_Exit(), " to 2441: 2441 Note: The _exit(), _Exit(), abort(), and exit() functions are defined in detail in the System Interfaces volume 2442 of IEEE Std 1003.1-2001. _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 drepper@redhat.com Defect in XBD Definitions (rdvk# 3) {ud-spawn} Tue, 22 Oct 2002 03:53:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Change the text to After a process is created by fork(), posix_spawn(), posix_spawnp() or vfork() , ... And update the list on 2428 accordingly _____________________________________________________________________________ Page: 119 Line: 2421 Section: Definitions Problem: Defect code : 2. Omission To be symmetric with other places the "Process Lifetime" definition should mention that process can also be created with the posix_spawn() functions. This assumes that "fork() functions", as used in the current text, includes vfork(). If not all four functions, for, vfork, posix_spawn, and posiw_spawnp should be mentioned. Action: In line 2421 change After a process is created with a fork () function, to After a process is created with a fork () posix_spawn() or function, Also, add posix_spawn() to the list in line 2428. _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 drepper@redhat.com Defect in XBD (rdvk# 2) {ud-process-35} Tue, 22 Oct 2002 05:16:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC As below , but the words "or thread" should be TSP shaded. _____________________________________________________________________________ Page: 295 Line: 10537 Section: Problem: Defect code : 1. Error The description if sched_param is written in a way as if only processes can have scheduling priorities. The text should be updated to reflect the possibility of threads heaving priorities. Action: Change line 10537 to: int sched_priority Process or thread execution scheduling priority. Change beginning of line 10549 to: Each process or thread is controlled [...] _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 ajosey@opengroup.org Defect in XBD sys/types.h (rdvk# 6) {pthread_t.} Wed, 6 Nov 2002 07:23:24 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Agree this is a defect, fwd concerns to the sponsor Add pthread_t after 12988 in (33303 p1051 says intent that thread_t could be a structure) _____________________________________________________________________________ Page: 367 Line: 12988 Section: sys/types.h Problem: Defect code : 1. Error Note: This was discussed in mail seq 3520-3524 but missed for TC1 (so better late than never...). The nature of the type pthread_t is ambiguous. On the one hand, pthread_t is defined in sys/types.h (page 366, line 12916) as an arithmetic type (page 367, line 12973-12974). On the other hand, the existence of the function pthread_equal (page 1545, line 33300) suggests that using the equality operator == on two objects of type pthread_t might not work portably. This is further supported by the explanation in the Rationale Section, which allows for definitions of pthread_t as structures. Commentary: The original POSIX threads working group intended that pthread_t be opaque. The specification was deliberately designed to allow pthread_t to be a structure for better validation checking support. (Except, of course, that we missed that annoying blanket statement that all the types were arithmetic... and apparently also failed to notice that the edit to add the exclusions wasn't complete.) Action: Propose an interpretation that this is an error in the specification to be forwarded to the sponsor. A future revision is recommended to add pthread_t to the list of exceptions on lines 12975 in _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 gwc@opengroup.org Defect in XBD unistd.h (rdvk# 1) [gwc unistd symlink] Thu, 19 Sep 2002 12:33:04 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 411 Line: 14602 Section: unistd.h Problem: Defect code : 1. Error The symlink() declaration is marked XSI on the unistd.h page. It is not marked XSI in XSH6, and the symlink() function was in POSIX.1a, so this is clearly just an editorial mistake. Action: Remove the XSI shading from the symlink() declaration on line 14602. _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 bmark@us.ibm.com Defect in XBD unistd.h (rdvk# 11) {IBM-011401} Tue, 14 Jan 2003 17:56:39 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Add Definition. _PC_2_SYMLINKS CROSS VOLUME CHANGE: If _PC_2_SYMLINKS is added, note that a change will also be needed to XRAT: delete P224 L9226-9227. _____________________________________________________________________________ Page: 404 Line: 14282 Section: unistd.h Problem: Defect code : 2. Omission Missing a definition of _CS_POSIX2_SYMLINKS to correspond to the _POSIX2_SYMLINKS definition on XCU:p19 L770. Action: Add Definition. _CS_POSIX2_SYMLINKS. _____________________________________________________________________________ objection Enhancement Request Number 12 jonhitchcock@hotmail.com Defect in XBD limits.h (rdvk# 12) {jjh-85} Mon, 20 Jan 2003 13:37:18 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC make changes as follows: XBD limits.h: change line 9127 "in a word or type int" to "in an int" Change line 9128 16->32 For lines 9095, 9131, 9119 , add CX shading _____________________________________________________________________________ Page: 257-258 Line: 9095-9131 Section: limits.h Problem: Defect code : 1. Error There is conflicting information about the minimum size of an int. XBD lines 9095, 9119 and 9131 specify that the minimum acceptable values of INT_MAX, UINT_MAX and INT_MIN are 2147483647, 4294967295 and -2147483647. XBD lines 9216-9217 say that 32-bit values are the minimum requirement in Issue 5 of the Open Group Base Specifications. XCU lines 35337 and 35419 (touch) claim that a signed int can hold time values up to January 18, 2038. However: XBD line 9128 specified that the minimum acceptable value of WORD_BIT is 16. XSH lines 4335-4340 (alarm) and 42884-42889 (sleep) appear to say that a strictly conforming applcation can only use unsigned int values up to 65535. [The wording is unchanged since POSIX.1-1988, and is not necessary in practice if unsigned ints are at least 32 bits.] Action: Decide what the minimum size is, and modify the standard accordingly. If XBD lines 9095, 9119 and 9131 are not changed, CX-shade them because the C standard only requires 16-bit ints. _____________________________________________________________________________ OBJECTION Enhancement Request Number 13 joannaf@sun.com Defect in XBD inttypes.h (rdvk# 16) {sunw-jf03-ld5} Tue, 18 Feb 2003 17:32:12 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Rationale for rejection, Joanna will file a DR against C,and depending on the response we may reopen this matter in the future _____________________________________________________________________________ Page: 241 Line: 8446-8447 Section: inttypes.h Problem: Defect code : 1. Error The specification for includes the following prototype declarations in XBD6 page 241 lines 8446-8447: intmax_t wcstoimax(const wchar_t *restrict, wchar_t **restrict, int); uintmax_t wcstoumax(const wchar_t *restrict, wchar_t **restrict, int); The problem is that wchar_t is not defined by inclusion of this header, nor is allowance made for including the appropriate header, within or . The specification for the wcstoimax() and wcstoumax() interfaces (XSH6, page 1614 lines 49714-49719) requires the inclusion of as well . This appears to leave broken as one can not include without also including . To do so will mean failures of an undefined type wchar_t will occur due to the prototype declarations. Action: Add after XBD6, page 240 line 8410 the line: "The header shall include the _____________________________________________________________________________ EDITORIAL Enhancement Request Number 14 bmark@us.ibm.com Defect in XBD math.h (rdvk# 14) {IBM-020701} Fri, 7 Feb 2003 20:22:45 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Fred T has filed a DR, so we will close this for the moment, depending on the response we may reopen the matter in the future _____________________________________________________________________________ Page: 264 Line: 9407 Section: math.h Problem: Defect code : 1. Error The spec states the following: "The following macros shall expand to integer constant expressions whose values are returned by ilogb (x) if x is zero or NaN, respectively. The value of FP_ILOGB0 shall be either {INT_MIN} or -{INT_MAX}. The value of FP_ILOGBNAN shall be either {INT_MAX} or {INT_MIN}." Normally, a statement like; " may make symbols from visible" is included in the description to allow required definitions to be visible. But for math.h this was not done, so INT_MIN and INT_MAX are not defined in math.h. Action: add " may make symbols from visible" in the description for math.h, say after line 9417. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 15 alex.neyman@auriga.ru Defect in XBD Headers - netinet/in.h (rdvk# 15) {111111} Wed, 12 Feb 2003 09:37:02 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC Response from the action was that Network byte ordering does not apply to sin_family This implies the following change change (all in network byte order) to: The sin_port and sin_addr members shall be in network byte order This then raises the question about sockaddr_in6 structure The same issue has been confirmed which had the second response: Yes, we need a similar change for sockaddr_in6: The sin6_port and sin6_addr members shall be in network byte order. sin6_family and sin6_scope_id are host byte order. The exact usage of sin6_flowinfo has not been defined, so we really can't make a statement about that in either direction. _____________________________________________________________________________ Page: 279 Line: 9952 Section: Headers Problem: Defect code : 1. Error The description of the sockaddr_in structure has the following wording: The header shall define the sockaddr_in structure that includes at least the following members (all in network byte order): sa_family_t sin_family AF_INET in_port_t sin_port Port number struct in_addr sin_addr IP address This statement is unclear whether sin_family member should also be converted to network byte order, that is, does one have to write something like "xx.sin_family = htons(AF_INET);". If it doesn't, this violates the statement "all members are in network byte order". If it does, then 1) the size of sa_family_t is not specified, thus it is unclear whether one should use htons(), htonl() or nothing 2) for systems with sa_family_t occupying more than 1 byte, it will break existing applications. Action: Change the wording in the phrase above to be more specific of the sin_family usage. _____________________________________________________________________________ OBJECTION Enhancement Request Number 16 joannaf@sun.com Defect in XBD unistd.h (rdvk# 13) {sunw-jf03-ld2} Wed, 5 Feb 2003 12:36:03 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 398-403 Line: 13998-14-262 Section: unistd.h Problem: Defect code : 3. Clarification required The requirements on when constants in unistd.h can be defined or undefined is unclear. This manifests itself in two ways: Issue 1: In SUSv2 for POSIX and XSI conformance there was no requirement that _POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC constants needed definitions in unistd.h as their value could be determined via calls to fpathconf()/pathconf() or the getconf utility to verify that the implementation support these. This is still the definition for SUSv3 in the conformance section of XBD6 Chapter 2, page 16, lines 659-667. However, the unistd.h page does not clearly match Chapter 2, page 16, lines 659-667. In particular with the first sentence on 695: "The following symbolic constants shall either be undefined or defined with a value other than -1." The unistd.h definition for _POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC constants both say: "This symbol shall always be set to a value other than -1." (see XBD page 399 lines 14052 and pages 399-400 lines 14084-14085). Clarification is required as the unistd.h definition does not make it clear the _POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC constants can be undefined in unistd.h and the requirement is: "If this symbol is defined in , it shall be defined to be a value other than -1. If it is not defined, the value of this symbol reported by fpathconf(), pathconf(), or sysconf(), shall be a value other than -1." Issue 2: In many places in XBD6 for the optional constant definitions in the unistd.h description on pages 399-403 the following wording is used: "If this symbol has a value other than -1 or 0, it shall have the value 200112L." Clarification is required as the unistd.h definition does not make it clear the optional constants can be undefined in unistd.h and the requirement is: "If this symbol is defined in , it shall be defined to be -1, 0, or 200112L. The value of this symbol reported by sysconf() shall either be -1 or 200112L." Action: For Issue 1: An interpretation is required along with the proposed changes: Change the sentence on XBD6 page 399 lines 14052 from: "This symbol shall always be set to a value other than -1." to "This symbol shall either be undefined or defined with a value other than -1." Change the sentence on XBD6 page 399-400 lines 14084-14085 from: "This symbol shall always be set to a value other than -1." to "This symbol shall either be undefined or defined with a value other than -1." For Issue 2: An interpretation is required along with the proposed changes: Where the following text is used in the definition of constants on pages 399-403: "If this symbol has a value other than -1 or 0, it shall have the value 200112L." This need to be changed to: "If this symbol is defined in , it shall be defined to be -1, 0, or 200112L. The value of this symbol reported by sysconf() shall either be -1 or 200112L." _____________________________________________________________________________ OBJECTION Enhancement Request Number 17 SHwareSyst@aol.com Defect in XBD 6.4 (rdvk# 17) {030224-01} Tue, 25 Feb 2003 08:26:50 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to end of XBD 6.3 (and do the changes below) "This standard provides no means of defining a wide character codeset." Add to XRAT 6.3 "The standard does not specify how wide characters are encoded or provide a method for defining wide characters in a charmap. It specifies ways of translating between wide characters and multibyte characters . The standard does not prevent an extension from providing a method to define wide characters." Please note that all line numbers refer to the 2001 edition of XBD6 and no text changed in that part of the standard in the 2003 edition. Opinion: Disagree with the submitter except for one editorial error in the example. Submitter's interpretation: - Example at L3847-L3852 says a null byte is allowed in the second or subsequent byte of a multibyte character definition. - L3719-L3723 says a null byte is NOT allowed in a single-shift encoding character definition. - There is no way to distinguish the intent of a given range declaration as defining a single-shift encoding character or a normal multibyte character, in the character set description file. Therefore, it cannot define a range declaration defining single-shift encoding characters that carries over a byte boundary. Submitter's proposal: - Add a new encoding format to explicitly specify single-shift encoding characters. Our interpretation: - L3719-L3723 clearly describes that a null byte cannot be in the second or subsequent bytes of a character, whether it is a single shift encoding character or a normal multibyte character. So, no need to distinguish between a single-shift encoding character and a normal multibyte character in the character set description file. - Example at L3847-L3852 may not be appropriate, but I don't think it's totally wrong. I think the example just mean how the specification of the range declaration would be interpreted. So, the result of the expansion of the range may not be always making a valid character. If the user specifies the range declaration that carries over a byte boundary, the result is the user's responsibility. The definition of in the example will be invalid, because a null byte is in the second byte. However, the user can also directly specify such an invalid declaration in the character set description file, although it may result in an error or unexpected behavior of the localedef utility. I don't see a difference between specifying a range declaration carrying over a byte boundary that causes null byte in the second or subsequent byte of a multibyte character, and specifying an invalid character declaration. That is, specifying: ... \d129\d254 will cause the same result as specifying: \d129\d254 \d129\d255 \d130\d00 \d130\d01 The result may contain an invalid declaration of a character, but that is user's responsibility. - Example at L3851-L3852 has an editorial error. Decimal constants shall be represented by two or three decimal digits, preceded by the escape character and 'd'. But, they have only one digit preceded by "\d". Our proposal: (1) Fix the editorial error in the example. Change L3851-L3852 from: \d130\d0 \d130\d1 to: \d130\d00 \d130\d01 (2) Apply the following changes: - Insert the following sentence after "the range." and before "For example, ..." at L3846: However, because this causes a null byte in the second or subsequent bytes of a character, such a declaration should not be specified. - Insert the following sentence between L3852 and L3853: The expanded declaration of the symbol in the above example is an invalid specification, because it contains a null byte in the second byte of a character. _____________________________________________________________________________ Page: 119 Line: 3824 Section: 6.4 Problem: Defect code : 2. Omission Synopsis: Incomplete specification of encoding requirements for single-shift state charsets. Background: (from C950.pdf) 3842 In lines defining ranges of symbolic names, the encoded value shall be the value for the first symbolic name in the range (the symbolic name preceding the ellipsis). Subsequent symbolic names defined by the range shall have encoding values in increasing order. Bytes shall be treated as unsigned octets, and carry shall be propagated between the bytes as necessary to represent the range. For example, the line: 3847 ... \d129\d254 3848 is interpreted as: 3849 \d129\d254 3850 \d129\d255 3851 \d130\d0 3852 \d130\d1 3853 The comment is optional. Also, 3885 6.4.1 State-Dependent Character Encodings 3886 This section addresses the use of state-dependent character encodings (that is, those in which the encoding of a character is dependent on one or more shift codes that may precede it). A single-shift encoding (where each character not in the initial shift state is preceded by a shift code) can be defined in the charmap format if each shift-code/character sequence is considered a multi-byte character, defined using the concatenated-constant format described in Section 6.4 (on page 117). as exampled above for a wide char range, and 3719 While in the initial shift state, all characters in the portable character set shall retain their usual interpretation and shall not alter the shift state. The interpretation for subsequent bytes in the sequence shall be a function of the current shift state. A byte with all bits zero shall be interpreted as the null character independent of shift state. Thus a byte with all bits zero shall never occur in the second or subsequent bytes of a character. Problem: As exampled by the definition of the wide character range above, a multi-byte character definition is allowed to have a as a second or subsequent byte. It's also missing the leading zeroes in the last two lines of the range expansion, but that's editorial. A single-shift encoding is expected to use the same formats for individual chars and ranges of chars, yet by Par. 3719 can NOT have a second byte as , i.e. for a range that carries over a byte boundary the next legitimate value is /d01, not /d00, yet there is no current way to distinguish the intent of a given char or range declaration as defining wide chars or single-shift chars. Nor is there a requirement an implementation declaring single-shift chars can not use the range notation when it has multiple shift chars with consecutive byte values in a charset it wishes to define. Thus a parser could blithely generate s, even though the chardef file otherwise looks perfectly legitimate to it. Action: This is a bit wordy to adequately show context Change lines 3824-3835 to read: 3824 The encoding part indicates the numeric code of an individual character value or the first character of a range of values. For a single-byte character value the code is specified as a decimal, octal, or hexadecimal constant in one of the following formats: 3826 "%cd%u", , 3827 "%cx%x", , 3828 "%c%o", , 3829 Decimal constants shall be represented by two or three decimal digits, preceded by the escape character and the lowercase letter d; for example, "\d05", "\d97", or "\d143". Hexadecimal constants shall be represented by two hexadecimal digits, preceded by the escape character and the lowercase letter x; for example, "\x05", "\x61", or "\x8f". Octal constants shall be represented by two or three octal digits, preceded by the escape character; for example, "\05", "\141", or "\217". In a portable charmap file, each constant represents an 8-bit byte. A multi-byte character value is encoded by concatenating the constants describing the individual byte values. When encoding a single-shift state character or range, the lowercase letter 's' shall be prepended to the combined constant to distinguish it from the encoding for a wide character. When constants... etc. and Change lines 3842-3852 to read: 3842 In lines defining ranges of symbolic names, the encoded value shall be the value for the first symbolic name in the range (the symbolic name preceding the ellipsis). Subsequent symbolic names defined by the range shall have encoding values in increasing order. Bytes shall be treated as unsigned octets, and carry shall be propagated between the bytes as necessary to represent the range, skipping the value "\d00" for a single-shift state character as any partial constant. As examples: the wide character range encoding ... \d129\d254 is interpreted as: \d129\d254 \d129\d255 \d130\d00 \d130\d01 and the single-shift state encoding ... s\d129\d254 is interpreted as: s\d129\d254 s\d129\d255 s\d130\d01 s\d130\d02 3853 The comment is optional. Rationale: Providing notations for single chars and ranges is a "good idea", IMO, and this gives equal flexibility to wide chars and single shift chars in using either method, keeping in mind a is not a valid element of a shifted char (which I think is another good idea). As support for wide characters is required because of the wide character interfaces, it is chosen as the default and the shift-state encodings, being wholly optional but permitted specifically, are required to indicate with the 's' they are being defined and need the special handling. Could also append the 's', as in "\d129\d254s", and reword accordingly, but this would slow a parser down, I would think. The alternatives, that I can see, is to insert verbiage somewhare to specifically prohibit shift-state char ranges from passing 255 as any part of their encoding, or from using range notation altogether, to go with the limitaion a single char definition will not have a nul as any of it's bytes. I'm against this as it would bloat the definition files for some charsets unnecessarily, and doesn't solve the problem of whether the implementation should store the value as successive bytes in the order given or whatever way it stores wide char values. A third one could be to require wide char definitions to begin with a leading part that would be stripped off and not used in determing the byte width of the char, just as a signal that a wide char is being defined. This bloats chardef files that do define wide charsets, however. Future Directions: This is stuff I think would be pretty easy to implement from a parsing and syntax analysis standpoint given the current standard and this fix as a base that I wouldn't mind seeing fill out this chapter a bit more. Conceptually, I view them as rounding out the combinatorial possibiliities of the syntax elements already present and leaving locking codes as implementtion defined. Adding keywords that would allow shifted chars to be mapped to wide char equivalents in the chardef file is potentially useful. The standard already specifies a basic mapping between the byte and wide "POSIX" char sets, and this could generalize it so it could be portable to other charsets as well. For flexibility, syntax could be added that allows referencing external chardef files, so a single file that specifies a large wide charset could be subindexed by smaller byte width chardef files. Allowing, for example, a "Sconst,const[,const...]" or "const,const[,const...]S" construct to specify single-shifted wide characters, and extending the mapping facility onto a range, or ranges, of single-shifted byte chars in the same or another file. Something like this could be useful to applications that work with larger subsets of Unicode-32, where a few shift-state codes could prevent a chardef from jumping to needing a three byte width versus two for wide char storage. Providing a syntax for allowing previously defined ranges of unshifted wide chars to specify a range of shifted byte values, and vice versa, with the back and forth mapping implicit. To ease this a means for aliasing symbolically groups of ranges could also be implemented, and usable perhaps in constructing LC_TYPE definitions in localedef files. _____________________________________________________________________________ OBJECTION Enhancement Request Number 18 drepper@redhat.com Defect in XBD (rdvk# 18) {ud-signal.h} Fri, 28 Mar 2003 06:50:48 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC 10857 has to be there. 10854 may be there for shading control, leave it to the editors ordering is historical and could be changed, in which case we could have all the CX stuff at the top , the XSI shaded items together and lastly the RTS line _____________________________________________________________________________ Page: 304 Line: 10854 Section: Problem: Defect code : 1. Error The definition of the siginfo_t type uses the CX marking inconsistently. The existence of the type is marked with CX. This is correct. But two members (si_signo and si_code) are also marked this way. These markings are unnecessary. Action: Remove CX marking on lines 10854 and 10857. _____________________________________________________________________________ OBJECTION Enhancement Request Number 19 drepper@redhat.com Defect in XBD (rdvk# 19) {ud-timer-3} Wed, 26 Mar 2003 09:28:24 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Go with number 1 candidate for interpretation rather than TC2? _____________________________________________________________________________ Page: 367 Line: 12967 Section: Problem: Defect code : 3. Clarification required I've cited one place but the problem actually stretches across several more. The situation: the man page defines that timer_t shall be an arithmetic type. So clearly uintptr_t is allowed. The timer_create() man page specifies that if the /evp/ parameter is NULL the function behaves as if the timer ID is stored in the sigev_value element, which is of type union sigval. The man page (XBD 301) specifies that union sigval has exactly the members: int sival_int void *sival_ptr Now, what happens if timer_t == uintptr_t? A uintptr_t value will usually not fit in an 'int' and 64-bit platforms. How will user code checking the sigval value? This point is left unclear in the timer_create() specification. Intentionally? Should it then be made clear that the implementation has to document the use? The background is that I want to have an implementation where the timer_t values are basically pointers. To satisfy the current requirements about the timer_t type I'll have to use type uintptr_t or something equivalent. The value would fir in the sigval object but would have to be accessed via sival_ptr. >From my perspective the requirement for timer_t to be an arithmetic type makes no sense. Where would such a requirement be used? If no requirement like that would be made timer_t could be void* and the implementation could document that sival_ptr has to be used. Otherwise, and *much* more restricting, the timer_t specification would have to say that timer_t must be an arithmetic type with sizeof(timer_t) <= sizeof(int). Action: Two solutions, pick one. As said, I favor #1 since #2 is severely limiting the possible implementation. 1. Remove requirement on type timer_t XBD 367, add after line 12988 timer_t (marked with TMR) XSH 1514, line 46750. Add new sentence at end: Whether the sival_int or sival_ptr element of the sigev_value member is used is implementation defined. 2. Restrict timer_t type XBD 367, after line 13001 add: * timer_t shall is an integer type with size not larger than /int/. XSH 1514, line 46749, replace with the /sigev_signo/ having a default signal number, and the /sigev_value.sival_int/ member having the value of (I chose this notation because "member .. of member ..." sounds awkward). _____________________________________________________________________________ OBJECTION Enhancement Request Number 20 drepper@redhat.com Defect in XBD Referenced Documents (rdvk# 20) {ud-ref1} Tue, 1 Apr 2003 18:39:12 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: xxxix Line: 0 Section: Referenced_Documents Problem: Defect code : 2. Omission A few more ISO 8859 standards have been finalized since the text last revised the last time. Currently the reference to ISO/IEC 8859 misses -11 and -16. Action: Add after line starting "Part 10": Part 11: Latin/Thai Alphabet Add after line starting "Part 15": Part 16: Latin Alphabet No. 10 _____________________________________________________________________________ OBJECTION Enhancement Request Number 21 joannaf@sun.com Defect in XBD math.h (rdvk# 21) {jf-al-FP_FAST-150403} Tue, 15 Apr 2003 18:48:32 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC _____________________________________________________________________________ Page: 264 Line: 9399 Section: math.h Problem: Edition of Specification (Year): 2001 Defect code : 3. Clarification required One of the VSX testsuite tests has the following test assertion and test strategy: /tset/C99.hdr/misc/math_1/T.math_1 7 Test Description: The header file contains macro definitions(if required) FP_FAST_FMA, FP_FAST_FMAF and FP_FAST_FMAL. Test Strategy: CALL clock() to get starting CPU usage PERFORM direct multiply-add operation 10000/SPEEDFACTOR times CALL clock() to get ending CPU usage CALL clock() to get starting CPU usage PERFORM the same 10000/SPEEDFACTOR multiply-add operations using fma() CALL clock() to get ending CPU usage IF FP_FAST_FMA is defined VERIFY that the fma() operations used time less than the CPU time that the direct operations used ELSE VERIFY that the fma() operations used time more than the CPU time that the direct operations used It is our assertion that test strategy is not correct in testing when FP_FAST_FMA is not defined that is the test: ELSE VERIFY that the fma() operations used time more than the CPU time that the direct operations used is not supported by the C99 specification or the Base Specifications Issue 6 which should mirror the C99 specification in intent. The C99 specification says: 7.12 Mathematics ... [#7] The macro FP_FAST_FMA is optionally defined. If defined, it indicates that the fma function generally executes about as fast as, or faster than, a multiply and an add of double operands.193) The macros FP_FAST_FMAF FP_FAST_FMAL are, respectively, float and long double analogs of FP_FAST_FMA. ... ____________________ 193Typically, the FP_FAST_FMA macro is defined if and only if the fma function is implemented directly with a hardware multiply-add instruction. Software implementations are expected to be substantially slower. Base Specifications Issue 6 does have different wording. It says on lines 9399 to 9406: The following optional macros indicate whether the fma() family of functions are fast compared with direct code: FP_FAST_FMA FP_FAST_FMAF FP_FAST_FMAL The FP_FAST_FMA macro shall be defined to indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. The other macros have the equivalent meaning for the float and long double versions. The Base Specifications Issue 6 language when taken with the C99 specification language does not imply the test ELSE VERIFY that the fma() operations used time more than the CPU time that the direct operations used The test should not test for anything if any of the FP_FAST_* macros are not defined. The language "indicate whether the fma() family of functions are fast compared with direct code", has been used to imply that the macro is a switch on two types of behaviour which is not the C99 intent. Action: To clarify the intent change the lines 9399 to 9406 to: The following optional macros indicate whether the fma() family of functions are fast compared with direct code: FP_FAST_FMA FP_FAST_FMAF FP_FAST_FMAL If defined, the FP_FAST_FMA macro shall indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. If undefined it is unspecified what the speed of execution is. The other macros have the equivalent meaning for the float and long double versions. _____________________________________________________________________________ COMMENT Enhancement Request Number 22 ienup.sung@sun.com Defect in XBD LC_CTYPE (rdvk# 22) {IS-XBD0} Thu, 1 May 2003 02:18:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The group felt there was no problem with the current standard that this proposed change would address. _____________________________________________________________________________ Page: 0 Line: 0 Section: LC_CTYPE Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The LC_CTYPE section of the Locale chapter specifies digit and xdigit classes as like the following: digit Define the characters to be classified as numeric digits. In the POSIX locale, only: 0 1 2 3 4 5 6 7 8 9 shall be included. In a locale definition file, only the digits , , , , , , , , , and shall be specified, and in contiguous ascending sequence by numerical value. The digits to of the portable character set are automatically included in this class. xdigit Define the characters to be classified as hexadecimal digits. In the POSIX locale, only: 0 1 2 3 4 5 6 7 8 9 A B C D E F a b c d e f shall be included. In a locale definition file, only the characters defined for the class digit shall be specified, in contiguous ascending sequence by numerical value, followed by one or more sets of six characters representing the hexadecimal digits 10 to 15 inclusive, with each set in ascending order (for example, , , , , , , , , , , , ). The digits to , the uppercase letters to , and the lowercase letters to of the portable character set are automatically included in this class. Looking at the above, many people are confused by whether the digit and the xdigit classes allow any other numeric digits that a locale can have other than the to the of the PCS. The reasons of the confusion are like the following: 1. It specifies that each class can have characters to be classified as numeric or hexadecimal digits. Multiscript codesets has multiple numeric digits, e.g., Unicode has Arabic digits, Arabic-Indic digits, Devanagari digits, Fullwidth decimal digits, and so on. 2. It says "In the POSIX locale, only: 0 ~ 9 shall be included" in digit class giving out nuance of or possibly implying that other locales can have other digits not in PCS too. 3. And then it also says, "In a locale definition file, only the digits , ... and shall be specified, and in contiguous ascending sequence by numerical value. The digits to of the portable character set are automatically included in this class." in the digit class spec implying that only to of ten symbolic names for digits can be specified from the current charmap file. It seems there are a few problems here: 1. Almost all modern codesets except ASCII and Latin based codesets have more than one set of non-Arabic digits in their locales/languages. In certain cases, one locale/codeset can have multiple sets of digits too, for instance, Unicode and GB18030. 2. The spec does not explicitly mention in the most clear manner whether the digit class and the xdigit class must include only one set of decimal digits for 0 to 9, or, if they can include any other multiple sets of digits. 3. Symbolic names from the PCS table such as , , and so on from the Character Set section are, it seems, used with overloaded, unclear meanings, i.e., "" vs. " of the portable character set." Action: It would be quite desirable to either make the spec for the digit and the xdigit classes more clearer or expand a little as like the following (for the digit class only): digit Define the characters to be classified as numeric digits. In the POSIX locale, only: 0 1 2 3 4 5 6 7 8 9 shall be included. The digits to of the portable character set are automatically included in this class. When digits are specified in a locale definition file, they shall be specified in contiguous ascending sequence by numerical value. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 23 ajosey@opengroup.org Defect in XBD sys/types.h (rdvk# 23) {ag.3520-24} Wed, 21 May 2003 10:58:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_9 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 369 Line: 13053 Section: sys/types.h Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The type pthread_t is missing from the list of exceptions from being an arithmetic type. See PASC Interp 1003.1c-1995 #36. The original POSIX working group absolutely intended that pthread_t be opaque. The specification was deliberately designed to allow pthread_t to be a structure for better validation checking support. _____________________________________________________________________________ PASC Interpretation reference 1003.1c-95 #36 _____________________________________________________________________________ Interpretation Number: XXXX Topic: primitive system data types Relevant Sections: 2.5 Interpretation Request: ----------------------- Date: Mon, 07 Oct 1996 14:41:09 -0400 From: Dave Butenhof (butenhof@zko.dec.com) 1. Section 2.5, Primitive System Data Types The pthread data types (pthread_t, pthread_attr_t, pthread_cond_t, pthread_condattr_t, pthread_mutex_t, pthread_mutexattr_t, pthread_key_t, pthread_once_t) are listed in this section, and in Table 2-1. Unfortunately, while all of these types have been specifically described as "opaque" types (and 2.5 even reminds readers that there are "no defined comparison or assignment operators" for most of the types, oddly omitting some), The second paragraph of this section says clearly "All of the types listed in Table 2-1 shall be arithmetic types". 1a) This is not true, and the working group did not intend to make this a requirement. Either the statement should be changed, for example, to list the specific types that must be arithmetic, or to exclude all of those that needn't be -- or else the non arithmetic types (all the pthread types) should be moved to a separate table. 1b) In addition, the list of types for which there are no defined comparison or assignment operators omits pthread_key_t and pthread_once_t, both of which are also "opaque types", and have no comparison or assignment operators. Interpretation response ----------------------- The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale ------------- As noted in the request these types are described elsewhere in the standard as opaque types as an aid to extensibility. Although not part of the normative text, the rationale for POSIX 1003.1c/D10 makes it very clear that these are opaque data types. Furthermore, the text in lines 970-972 that "There are no defined comparison or assignment operators for the types pthread_attr_t, pthread_cond_t, pthread_condattr_t, pthread_mutex_t, and pthread_mutex_attr_t." contradicts the claim on line 963 that these types shall be arithmetic, since all arithmetic types have defined comparison and assignment operators. The interpretations committee recommends to the sponsor that the following changes be made: Proposed changes to 1003.1 (not part of this interpretation). -------------------------- Change 1003.1-1996 ll 963 first sentence from "All of the types listed in Table 2-1 shall be arithmetic types;" To: "All of the types listed in Table 2-1 shall be arithmetic types, except the types pthread_t, pthread_attr_t, pthread_mutex_t, pthread_mutexattr_t, pthread_cond_t, pthread_condattr_t, pthread_key_t, pthread_once_t;" Forwarded to Interpretations group: Oct 20 1996 Proposed interpretation:29 Jan 97 Finalised: Feb 18 1997 Action: Add pthread_t to the list before pthread_attr_t _______________________________________________________________________________ OBJECTION Enhancement Request Number 24 joannaf@sun.com Defect in XBD 6.4 Character Set Description File (rdvk# 24) {jf-kt-sun-210503-2} Wed, 21 May 2003 16:38:12 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: TC We think the XBD6 should allow the value zero for the width value of WIDTH and WIDTH_DEFAULT. Change "WIDTH An unsigned positive integer value defining" to "WIDTH A non-negative integer value defining" and change "WIDTH_DEFAULT An unsigned positive integer value defining" to "WIDTH_DEFAULT A non-negative integer value defining" _______________________________________________________________________________ Page: 121-122 Line: 3873-3885 Section: 6.4 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The width information in locale does not cover some existing locales. In XBD6, at lines 3873-3885, pages 121-122, 'WIDTH' and 'WIDTH_DEFAULT' for the charmap file to be specified to the localedef utility are defined as follows: WIDTH An unsigned positive integer value defining the column width for the printable characters in the coded character set specified in Table 6-1 and Table 6-2. Coded character set character values shall be defined using symbolic character names followed by column width values. Defining a character with more than one WIDTH produces undefined results. The END WIDTH keyword shall be used to terminate the WIDTH definitions. Specifying the width of a non-printable character in a WIDTH declaration produces undefined results. WIDTH_DEFAULT An unsigned positive integer value defining the default column width for any printable character not listed by one of the WIDTH keywords. If no WIDTH_DEFAULT keyword is included in the charmap, the default character width shall be 1. So, for WIDTH and WIDTH_DEFAULT, the spec. says an unsigned positive integer value can be specified. This does not cover some existing locales. The UTF-8-based locales such as en_US.UTF-8 and ja_JP.UTF-8 define a lot of printable character whose display width is 0. It seems this is pretty normal in the Unicode world. Therefore, wcwidth() function returns 0 for those characters in our UTF-8 locales. But, such locales cannot be defined by using the new WIDTH keyword, because '0' is not a valid input to the WIDTH definition. For example, the following characters have width 0 on Solaris: ... ... ... These are non-spacing characters. Other characters than non-spacing characters may have width 0. Looking at the UTF-8 charmap included in the GNU libc 2.3.2, it has a similar width definition to the Solaris one. Action: We think the XBD6 should allow the value zero for the width value of WIDTH and WIDTH_DEFAULT. Change "WIDTH An unsigned positive integer value defining" to "WIDTH An unsigned positive integer value or the value zero defining" and change "WIDTH_DEFAULT An unsigned positive integer value defining" to "WIDTH_DEFAULT An unsigned positive integer value or the value zero defining" _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 joannaf@sun.com Defect in XBD 7.3.3 LC_MONETARY (rdvk# 25) {jf-kt-dc-180603 } Wed, 18 Jun 2003 14:32:38 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 144 Line: 4868-4871 Section: 7.3.3 Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The wording in XBD6 page 144 lines 4868-4871: 4868 int_n_sep_by_space An integer set to 0 if no space separates the int_curr_symbol from the 4869 value for a monetary quantity with a negative value, set to 1 if a space 4870 separates the symbol from the value, and set to 2 if a space separates the 4871 symbol and the sign string, if adjacent. Is ambiguious unless taken with the wording in XRAT6 page 49, lines 1962-1966: 1962 The locale definition is an extension of the ISO C standard localeconv ( ) specification. In 1963 particular, rules on how currency_symbol is treated are extended to also cover int_curr_symbol, 1964 and p_set_by_space and n_sep_by_space have been augmented with the value 2, which places 1965 a between the sign and the symbol (if they are adjacent; otherwise, it should be treated 1966 as a 0). The following table shows the result of various combinations: This XBD6+XRAT6 meaning though is in conflict with the wording in localeconv() in XSH6 page 699 lines 23075-23078 which matches wording in C99 subclause 7.11.2.1.: 23075 2 If the currency symbol and sign string are adjacent, a space separates them; otherwise, a 23076 space separates the sign string from the value. 23077 For int_p_sep_by_space and int_n_sep_by_space, the fourth character of int_curr_symbol is 23078 used instead of a space. Action: We believe the changes needed to eliminate this ambiguity and conflict are as follows: 1) The descriptions of p_sep_by_space, n_sep_by_space, int_p_sep_by_space, and int_n_sep_by_space need to be updated to match the description of these keywords in C99 and XSH6 localeconv() (XSH6 page 698-699, lines 23031-23033, 23037-23039, 23052-23057 and 23070-23078). Change XBD6 page 143 lines 4836-4839 from: 4836 p_sep_by_space An integer set to 0 if no space separates the currency_symbol from the 4837 value for a monetary quantity with a non-negative value, set to 1 if a 4838 space separates the symbol from the value, and set to 2 if a space 4839 separates the symbol and the sign string, if adjacent. to "p_sep_by_space Set to a value indicating the separation of the currency_symbol, the sign string, and the | value for a non-negative formatted monetary quantity. The values of p_sep_by_space, n_sep_by_space, int_p_sep_by_space, and int_n_sep_by_space are interpreted according to the following: 0 No space separates the currency symbol and value. 1 If the currency symbol and sign string are adjacent, a space separates them from the value; otherwise, a space separates the currency symbol from the value. 2 If the currency symbol and sign string are adjacent, a space separates them; otherwise, a space separates the sign string from the value." Change XBD6 page 143 lines 4843-4846 from: 4843 n_sep_by_space An integer set to 0 if no space separates the currency_symbol from the 4844 value for a monetary quantity with a negative value, set to 1 if a space 4845 separates the symbol from the value, and set to 2 if a space separates the 4846 symbol and the sign string, if adjacent. to "n_sep_by_space Set to a value indicating the separation of the currency_symbol, the sign string, and the value for a negative formatted monetary quantity." Change XBD6 page 143 lines 4864-4867 from: 4864 int_p_sep_by_space An integer set to 0 if no space separates the int_curr_symbol from the 4865 value for a monetary quantity with a non-negative value, set to 1 if a 4866 space separates the symbol from the value, and set to 2 if a space 4867 separates the symbol and the sign string, if adjacent. to "int_p_sep_by_space Set to a value indicating the separation of the int_curr_symbol, the sign string, and the value for a non-negative internationally formatted monetary quantity." Change XBD6 page 143 lines 4868-4871 from: 4868 int_n_sep_by_space An integer set to 0 if no space separates the int_curr_symbol from the 4869 value for a monetary quantity with a negative value, set to 1 if a space 4870 separates the symbol from the value, and set to 2 if a space separates the 4871 symbol and the sign string, if adjacent. to "int_n_sep_by_space Set to a value indicating the separation of the int_curr_symbol, the sign string, and the value for a negative internationally formatted monetary quantity." 2) The rationale on XRAT6, page49, lines 1962-1978 needs to be updated to match the C99 requirements and to note that this is an incompatible change from UNIX 98 (and probably POSIX.2-1992 and POSIX.1-1996) requirements. On XRAT6 page 49, lines 1962-1966 change: 1962 The locale definition is an extension of the ISO C standard localeconv ( ) specification. In 1963 particular, rules on how currency_symbol is treated are extended to also cover int_curr_symbol, 1964 and p_set_by_space and n_sep_by_space have been augmented with the value 2, which places 1965 a between the sign and the symbol (if they are adjacent; otherwise, it should be treated 1966 as a 0). The following table shows the result of various combinations: to "The locale definition is an extension of the ISO C standard localeconv() specification. In particular, rules on how currency_symbol is treated are extended to also cover int_curr_symbol, and p_set_by_space and n_sep_by_space have been augmented with the value 2, which places a between the sign and the symbol. This has been updated to match the C99 requirements and is an incompatible change from UNIX 98 and POSIX.2-1992 and POSIX.1-1996 requirements. The following table shows the result of various combinations:" 3) After #1 above, consider stripping all of the description of these keywords in XSH6, pages 697-699 to just be a pointer to XBD (so we don't run into the problem of two places in the standard giving conflicting requirements as we update one of these sections in the future). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 ajosey@opengroup.org Defect in XBD limits.h (rdvk# 26) {limits.h.charclass_name_max} Tue, 17 Jun 2003 11:59:28 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 260 Line: 9191 Section: limits.h Problem: Edition of Specification (Year): 2003 Defect code : 1. Error CHARCLASS_NAME_MAX is defined under "Runtime Increasable Values" and also "Other Invarient Values". This is an integration issue with the base specifications. It should be removed from the latter location. Action: In the DESCRIPTION section Under "Other Invariant Values" Remove lines 9191-9193 "XSI {CHARCLASS_NAME_MAX} Maximum number of bytes in a character class name. Minimum Acceptable Value: 14" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 27 ajosey@opengroup.org Defect in XBD unistd.h (rdvk# 27) {limits.h-symbols} Fri, 13 Jun 2003 16:24:46 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: Add _SC_SS_REPL_MAX, _SC_TRACE_EVENT_NAME_MAX, _SC_TRACE_NAME_MAX, _SC_TRACE_SYS_MAX and _SC_TRACE_USER_EVENT_MAX in alphabetical order to unistd.h (they are unshaded since TC1 decided that support for the announcement symbols is mandatory). (CROSS VOLUME CHANGE) On the sysconf() page on XSH page 1474 add _POSIX_SS_REPL_MAX _SC_SS_REPL_MAX _POSIX_TRACE_EVENT_NAME_MAX _SC_TRACE_EVENT_NAME_MAX _POSIX_TRACE_NAME_MAX _SC_TRACE_NAME_MAX _POSIX_TRACE_SYS_MAX _SC_TRACE_SYS_MAX _POSIX_TRACE_USER_EVENT_MAX _SC_TRACE_USER_EVENT_MAX In XSH sysconf() add to RETURN VALUE If the variable corresponding to /name/ is dependent on an unsupported option the results are unspecified. AJ action: do similar for pathconf() In XSH sysconf() add to APPLICATION USAGE Application writers should check whether an option, such as _POSIX_TRACE is supported, prior to obtaining and using values for related variables such as _POSIX_TRACE_NAME_MAX. In XSH pathconf/fpathconf add to RETURN VALUE as new third paragraph If the variable corresponding to /name/ is dependent on an unsupported option the results are unspecified. In XSH pathconf/fpathconf add to APPLICATION USAGE Application writers should check whether an option, such as _POSIX_ADVISORY_INFO is supported, prior to obtaining and using values for related variables such as POSIX_ALLOC_SIZE_MIN. _____________________________________________________________________________ Page: 410 Line: 14564 Section: unistd.h Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The symbols SS_REPL_MAX, TRACE_EVENT_NAME_MAX, TRACE_NAME_MAX, TRACE_SYS_MAX and TRACE_USER_EVENT_MAX may be defined in . If they are not defined in then it says that the actual value supported by a specific instance shall be provided by the sysconf() function. However the corresponding _SC_* constants are missing from and the sysconf manual pages. Action: Add _SC_SS_REPL_MAX, _SC_TRACE_EVENT_NAME_MAX, _SC_TRACE_NAME_MAX, _SC_TRACE_SYS_MAX and _SC_TRACE_USER_EVENT_MAX in alphabetical order to unistd.h (they are unshaded since TC1 decided that support for the announcement symbols is mandatory). (CROSS VOLUME CHANGE) On the sysconf() page on XSH page 1474 add _POSIX_SS_REPL_MAX _SC_SS_REPL_MAX _POSIX_TRACE_EVENT_NAME_MAX _SC_TRACE_EVENT_NAME_MAX _POSIX_TRACE_NAME_MAX _SC_TRACE_NAME_MAX _POSIX_TRACE_SYS_MAX _SC_TRACE_SYS_MAX _POSIX_TRACE_USER_EVENT_MAX _SC_TRACE_USER_EVENT_MAX (I am assuming that if the sporadic scheduler or tracing are not supported the sysconf value returned will be the _POSIX_* minimum maximum and that applications would determine support using the appropriate option symbols in . Do we need to say this anywhere in rationale?) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 28 Markus.Kuhn@cl.cam.ac.ukDefect in XBD 4.14 Seconds Since the Epoch (rdvk# 28) {1} Thu, 3 Jul 2003 19:27:53 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 102 Line: 3207 Section: 4.14 Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The sentence starting in line 3207 How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time are made is implementation-defined. is grammatically incorrect, because the phrase "are made" appears twice. This typo persists in the 2003 edition: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14 Action: Remove the second occurance of "are made" from the sentence starting in line 3207, such that it reads How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. and review the resulting sentence for grammatical correctness. _____________________________________________________________________________ COMMENT Enhancement Request Number 29 drepper@redhat.com Defect in XBD (rdvk# 29) {ud-stat-timespec} Thu, 26 Jun 2003 20:10:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add before "Times shall be given..." on line 12708: The timespec structure may be defined as described in . _____________________________________________________________________________ Page: 358 Line: 12708 Section: Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Many systems today report acc/modification/status times in the stat information with more than second resolution. One frequently used method is to report fractions of a second in nanoseconds. I.e., the time information is effectively similar to struct timespec. In fact, some systems (Linux, Solaris) could actually use struct timespec. This would probably be the preferred method. But struct timespec cannot be used in since timespec violates the namespace rules for this header. Action: Add before "Times shall be given..." on line 12708: The timespec structure may be defined as described in . _____________________________________________________________________________ OBJECTION Enhancement Request Number 30 ajosey@opengroup.org Defect in XBD 3.187_Group_Database (rdvk# 30) {impldef.1} Thu, 7 Aug 2003 15:15:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change From: "A system database of implementation-defined format that contains at least the following information for each group ID:" To: "A system database hat contains at least the following information for each group ID:" _____________________________________________________________________________ Page: 61 Line: 2005 Section: 3.187_Group_Database Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text says that this is "A system database of implementation-defined format". Use of this term requires the PCD to document the format. There is no benefit to portable applications to know the format. Action: Change "implementation-defined" to "unspecified" _____________________________________________________________________________ OBJECTION Enhancement Request Number 31 ajosey@opengroup.org Defect in XBD 3.382_System_Console (rdvk# 31) {impldef} Thu, 7 Aug 2003 15:19:00 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "An implementation-defined device" to: "A device" Note that there is an impl-defined rqt in section 10 _____________________________________________________________________________ Page: 88 Line: 2778 Section: 3.382_System_Console Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text says that this is "an implementation-defined device". Use of this term requires the PCD to document the characteristics of the device, yet there is no benefit to portable applications to know the format. Action: Change "implementation-defined" to "unspecified" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 32 don.cragun@sun.com Defect in XBD 3.382 System Console (rdvk# 32) {dwc-S.C.20030807} Thu, 7 Aug 2003 15:25:44 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 88 Line: 2779 Section: 3.382 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Typo. Action: Change "MM_CONSOLE flat" on P88, L2779 to "MM_CONSOLE flag". _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 ajosey@opengroup.org Defect in XBD 3.385_System_Process (rdvk# 33) {impldef} Thu, 7 Aug 2003 15:20:51 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change From: An implementation-defined object, other than a process executing an application, that has a process ID. To: An object other than a process executing an application, that is provided by the system and has a process ID. _____________________________________________________________________________ Page: 88 Line: 2801 Section: 3.385_System_Process Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text says that this is "an implementation-defined object". Use of this term requires the PCD to document the characteristics of the object, yet there is no benefit to portable applications to know that information. Action: Change "implementation-defined" to "unspecified" _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 ajosey@opengroup.org Defect in XBD 3.386_System_Reboot (rdvk# 34) {impldef} Thu, 7 Aug 2003 15:22:11 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 89 Line: 2805 Section: 3.386_System_Reboot Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text says that this is "an implementation-defined sequence of events". Use of this term requires the PCD to document the characteristics of the sequence, yet there is no benefit to portable applications to know that information. Action: Change "implementation-defined" to "unspecified" _____________________________________________________________________________ COMMENT Enhancement Request Number 35 ajosey@opengroup.org Defect in XBD 3.393_Thread (rdvk# 35) {impldef} Thu, 7 Aug 2003 15:25:59 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Restore to .1-1996 wording "Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc( ), directly addressable storage obtained through implementation-supplied functions, and automatic variables, are accessible to all threads in the same process." Action: (Andrew look for other occurrences, I did and cannot find others in .1-1996. We need to consider text for the rationale to highlight the difference between impl-defined and impl-supplied _____________________________________________________________________________ Page: 90 Line: 2884 Section: 3.393_Thread Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The text says that "Anything whose address may be determined by a thread, including but not limited to static variables, storage obtained via malloc( ), directly addressable storage obtained through implementation-defined functions, and automatic variables, are accessible to all threads in the same process." Use of the term implementation-defined requires the PCD to document the functions as noted above. Is there benefit to this? Or do we really want to say unspecified or do we want to drop that part of the sentence? Action: Change "implementation-defined" to "unspecified" or remove "directly...functions" _____________________________________________________________________________ OBJECTION Enhancement Request Number 36 ajosey@opengroup.org Defect in XBD 3.424_User_Database (rdvk# 36) {impldef.1} Thu, 7 Aug 2003 15:17:03 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change From: "A system database of implementation-defined format that contains". To: "A system database that contains". _____________________________________________________________________________ Page: 94 Line: 2939 Section: 3.424_User_Database Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text says that this is "A system database of implementation-defined format". Use of this term requires the PCD to document the format. There is no benefit to portable applications to know the format. Action: Change "implementation-defined" to "unspecified" _____________________________________________________________________________ COMMENT Enhancement Request Number 37 ajosey@opengroup.org Defect in XBD 10.2 (rdvk# 37) {comment} Tue, 12 Aug 2003 17:18:46 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change From: The implementation shall document which terminal types it supports and which of these features and utilities are not supported by each terminal. To: The implementation shall document in the system documentation which terminal types it supports and which of these features and utilities are not supported by each terminal. _____________________________________________________________________________ Page: 185 Line: 6540 Section: 10.2 Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required Section 10.2 requires that the PCD shall document which terminal types the system supports and which of the features and utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 that are not supported by each terminal. Contrast this to the lp utility where it explicitly uses unspecified rather than implementation-defined and states: "The term unspecified is used in this section in lieu of implementation-defined as most known implementations would not be able to make definitive statements in their conformance documents; the existence and usage of printers is very dependent on how the system administrator configures each individual system." The variety of terminal support would appear to be a similar case to printers. Action: Consider making the requirement unspecified rather than implementation-defined, or a more general requirement on classes of terminals? _____________________________________________________________________________ OBJECTION Enhancement Request Number 38 ajosey@opengroup.org Defect in XBD sys_utsname.h (rdvk# 38) {implspec} Fri, 8 Aug 2003 09:38:09 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change From: "Name of this node within an implementation-defined communications network." To: "Name of this node within the communications network to which this node is attached,if any." _____________________________________________________________________________ Page: 373 Line: 13189 Section: sys_utsname.h Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The text describes the char nodename[] member as "Name of this node within an implementation-defined communications network." This will require the PCD to document the network characteristics. I could understand, an "implementation-defined Name of this node within...". The wording changed between 1990/1996 edition and the present edition, previously the term implementation-specified, which was a non term. This would seem to make better sense here to be an "unspecified communications network" that is we are not specifying here what that network is. A corresponding change will also be needed in XSH p1557, line 48072. Action: Change "implementation-defined" to "unspecified"