From lrajchel@ANSI.org Thu Jan 11 16:54:52 2001 Received: from email1.ansi.org (mail.ansi.org [165.254.114.6]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id QAA76958; Thu, 11 Jan 2001 16:54:50 +0100 (CET) (envelope-from lrajchel@ANSI.org) Received: by email1.ansi.org with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 10:54:16 -0500 Message-ID: <2F81C8110D55D411882A0020356797B2151A74@email1.ansi.org> From: Lisa Rajchel To: "'sc22info@dkuug.dk'" Cc: "'Simonsen, Keld'" Subject: FW: SC 22 N 3202 - Summary of Voting on SC 22 N 3161, Concurrent CD Registration and FCD Approval Ballot for the revision of ISO/IEC 9945- 1 - Information technology - Portable Operating System Interface (POSIX) - Part Date: Thu, 11 Jan 2001 10:54:13 -0500 Importance: high X-Priority: 1 X-Mailer: Internet Mail Service (5.5.2650.21) > _______ beginning of title page _________________________ > ISO/IEC JTC 1/SC22 > Programming languages, their environments and system software interfaces > Secretariat: U.S.A. (ANSI) > ISO/IEC JTC 1/SC22 > N3202 > TITLE: > Summary of Voting on SC 22 N 3161, Concurrent CD Registration and FCD > Approval Ballot for the revision of ISO/IEC 9945-1 - Information > technology - Portable Operating System Interface (POSIX) - Part 1 > > DATE ASSIGNED: > 2001-01-10 > > SOURCE: > Secretariat, ISO/IEC JTC 1/SC22 > BACKWARD POINTER: > N/A > > DOCUMENT TYPE: > Summary of Voting > PROJECT NUMBER: > 22.21.03.03, 22.21.02.01, 22.21.02.03, 22.21.04.01, 22.21.04.01.01, 22.39 > -22.43 > STATUS: > WG 15 is requested to prepare a Disposition of Comments Report addressing > the comments received from the Nationanl Bodies and to prepare a revised > text and a recommendation for further processing. > > ACTION IDENTIFIER: > FYI and action by WG 15 > > DUE DATE: > N/A > DISTRIBUTION: > Text > > CROSS REFERENCE: > N/A > > DISTRIBUTION FORM: > Def. > > Address reply to: > ISO/IEC JTC 1/SC22 Secretariat > Lisa Rajchel > ANSI > 11 West 42nd Street > New York, NY 10036 > Telephone: (212) 642-4932 > Fax: (212) 840-2298 > Email: lrajchel@ansi.org <> > > > _______ end of title page; beginning of summary ______________ > SUMMARY OF VOTING ON > > Letter Ballot Reference No: SC22 N3161 > Circulated by: JTC 1/SC22 > Circulation Date: 2000-08-29 > Closing Date: 2000-12-30 > > SUBJECT: Summary of Voting on SC 22 N 3161, Concurrent CD > Registration and FCD Approval Ballot for the revision of ISO/IEC 9945-1 - > Information technology - Portable Operating System Interface (POSIX) - > Part 1 > > __________________________________________________________________________ > ______________ > ---------------------------------------------------------------------- > > The following responses have been received on the subject of CD > registration: > "P" Members supporting CD registration without comment > 10 (Canada, Denmark, Egypt, Japan, Rep. of Korea, Netherlands, Norway, > Russian Federation, UK, USA) > "P" Members supporting CD registration with comments 0 > > "P" Members not supporting CD registration 0 > > "P" Members abstaining > 1 (Austria) > "P" Members not voting > 11 (Belgium, Brazil, China, Czech Rep., Finland, France, Germany, Ireland, > Romania, Slovenia, Ukraine) > > The following responses have been received on the subject of FCD approval: > "P" Members supporting FCD approval without comment > 6 (Denmark, Egypt, Japan, Netherlands, Rep. of Korea, Russian Federation) > "P" Members supporting FCD approval with comments > 3 (Norway, UK, USA) - Comments are provided at the end of the summary > > "P" Members not supporting FCD approval > 1 (Canada) > > "P" Members abstaining > 1 (Austria) > "P" Members not voting > 11 (Belgium, Brazil, China, Czech Rep., Finland, France, Germany, Ireland, > Romania, Slovenia, Ukraine) > > Comments supporting FCD approval > > Norwegian comments > It should be assured that the name of the standard in ISO and IEC terms be > prevalent throughout the standard, such as ISO/IEC 9945-1:2001 everywhere > IEEE Std 1003.1 is listed. > > UK comments > The UK approves SC 22 N 3161 with the comment that the Disposition of > Comments being developed by the joint Working Group be implemented in the > final draft. These dispositions are in the detailed change request > reports being developed by the joint Working Group ("The Austin Group"). > The UK also has the following additional comments attached at the end of > this summary. > > USA comments > Before issuing this document for ballot in the next stage of the ISO/IEC > approval process, changes should be made to the draft to address any > issues raised in the IEEE and Open Group ballots on this draft as > specified by the Austin Group ballot resolution committee, in addition to > any issues raised in the ISO/IEC FCD ballot. > > Comments NOT supporting FCD approval > > Canadian comments > Because the version of the document submitted for balloting (draft 4) is > still in development, significant and substantive changes can be expected > to it before it becomes a final draft (draft 6+). Therefore, while we > vote in favour of approving the CD registration and CD approval, we vote > against FCD Approval pending receipt of a "final" draft. > > Additional UK Comments > (xbd) > Page: xix Line: 705 Section: Preface > Problem: > There's no mention of XRAT. > Action: > At 705: > * Rationale (Informative). > (xbd) > Page: 27 Line: 917 Section: 2.1.5.2 > Problem: > The law w.r.t. US export of encryption keeps changing. > Action: > Make it non country specific > change line 917 to > "Due to export restrictions on the decoding algorithm in some countries, > implementations may be..." > (xbd) > Page: 116 Line: 3251-3252 Section: 3.433 > Problem: > (white space: character) > The term is defined (XBD6d4, P107, L3007-3013) to be a synonym for > "tab character". Therefore, the phrase " character" expands to "tab > character character". > Note that other changes are needed here as well! > Action: > Change "( and characters)," on P116, L3251-3252 to > "(s > and s),". > (xbd) > Page: 125 Line: 3483-3495 Section: Seconds > Problem: > The rationale at lines 842-876 of XRATd4 needs further rework. > Action: > Replace 3495 with: > The relationship between the actual time of day and the current value > for Seconds Since the Epoch is unspecified. > 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 implemetation-defined. As represented in Seconds Since the > Epoch, each day shall be accounted for by exactly 86400 seconds. > Add to rationale (repl 1463): > The topic of whether Seconds Since the Epoch should account for leap > seconds has been debated upon a number of occasions, and each time > consensus was reached (with acknowleged dissent each time) that the > majority of users are best served by treating all days identically. > (That is, the majority of applications were judged to assume a single > length (as measured in Seconds Since the Epoch) for all days.) > Those applications which do care about leap seconds can determine how > to handle them in whatever way it felt was best for that application. > This was particularly emphasized because there was disagreement about what > the > best way of handling leap seconds might be. It is a practical impossiblity > to mandate that a conforming implementattion must have a fixed > relationship > to any particular official clock (consider isloated systems, or systems > performing "reruns" by setting the clock to some arbitrary time). > Note that as a practical consequence of this, the length of a second > as measured by some external standard is not specified. Applications > must be matched to a system that provides the particular handling of > external time in the way required by the application. > (xbd) > Page: 135 Line: 3805 Section: 6.1 > Problem: > POSIX-2 uses some names for control characters in addition to the > ones in Table 6.1, namely table 6.2 > Action: > Add p 135, line 3811 "Characters defined in Table 6-2 > on p xx may also be used in character set description files." > (xbd) > Page: 170-174 Line: 5215-5391 Section: LC_TIME > Problem: > The XSI shading is confusing, and may even be wrong. If you > ignore the XSI-shaded text, then: > a) lines 5218-5264 have no introduction to say what the constants > can be used for, > b) line 5369 is a heading for a table with no entries, > c) the POSIX locale values for LC_TIME are only defined as localedef > text. For other categories, the POSIX locale values are defined > twice: once as localedef text, and again as a human-readable table. > Action: > Rework chapter 7 editorially. > Reword introduction to 7.3.5.2 to show that the entire section is XSI. > Move > all examples in chapter 7 to XRAT so chap 7 more aligned with original .2. > Change 5266 table header last col to "Conversion Specifier/Modifier" > (xbd) > Page: 187 Line: 5908 Section: 8.1 > Problem: > Although correct, this can be misleading because of the fact that > environment variables are most visible through the shell, and > environment variables which are numbers do very strange things > in the shell environment (because they become parameter numbers). > Action: > Use: > at line 5908-5910, append to end of sentence "and shall not begin with > a digit." > After 5915, add note: "Other applications may also have difficulty > dealing with environment variable names that start with a digit. For > this reason use of such names is not recommended anywhere." > After 1883 in XRAT add: "In addition to the obvious conflict with the > shell syntax for positional parameter substitution, some historical > applications including some shells exclude names with leading digits > from the environment." > (xbd) > Page: 236 Line: 7735 Section: > Problem: > The text currently says: > The header shall define the following constants: > and then goes on to introduce `complex'. But `complex' is a macro > expanding to a name of a type. Also, it is not clear from this text > that all complex, _Complex_I, imaginary, _Imaginary_I, and I are > macros which can be undefined and redefined if necessary. > Action: > Replace line 7735 with: > The header shall define the following macros: > Replace lines 7744-7745 with: > The macros imaginary and _Imaginary_I shall > be defined if and only if the implementation supports imaginary types. > Replace line 7746 with: > An application may undefine and then, perhaps, redefine > the complex, imaginary, and I macros. > (xbd) > Page: 265 Line: 8617-8618 Section: fnmatch.h > Problem: > () > The requirements what is to be defined by does not match the > other headers in this draft. > Action: > Change "flags and ... are defined:" on P265, L8617-8618 to "flags:". > OB shade 8623 (and remove LEGACY), Change the > description for FNM_NOSYS to "Reserved", check CH. > (xbd) > Page: 273 Line: 8834 Section: inttypes.h > Problem: > I think you meant "stdint.h". > Action: > "stdin" -> "stdint". > (xbd) > Page: 323 Line: 10718,10739 Section: > Problem: > The pthread_attr_getstack() and pthread_attr_setstack() functions > are not mentioned in the header. > Action: > Add before line 10718: > int pthread_attr_getstack(const pthread_attr_t *restrict attr, > void **restrict stackaddr, > size_t *restrict stacksize); > Add before line 10730: > int pthread_attr_setstack (pthread_attr_t *attr, void *stackaddr, > size_t __stacksize); > (xbd) > Page: 352 Line: 11747 Section: stdint.h > Problem: > The term "width" has a special meaning in C99 which isn't in the XBD > terminology. > Action: > Append a paragraph: > Note: the "width" of an integer type is the number of bits used to > store its value in a pure binary system; the actual type may use more > bits than that (e.g. a 28 bit type could be stored in 32 bits of > actual storage). An N bit signed type has values in the range > N-1 N-1 N-1 > -2 or 1-2 to 2 -1, while an N bit unsigned type has values in > N > the range 0 to 2 -1. > (xbd) > Page: 354 Line: 11823 Section: stdint.h > Problem: > Optionality of type names is both hard to test for at compile time > and not very helpful. In the POSIX context, could these be required? > Action: > Add NOTE to end of section to > the effect that applications can test for optional types here by using the > corresponding limit macro. > Make intptr_t and uintptr_t XSI shaded and mandatory. > (xbd) > Page: 358 Line: 11975 Section: stdio.h > Problem: > There is no mention of the minimum limit on non-XSI systems. > Action: > Change the line to : > The value of {TMP_MAX} is at least 25. [shadeon] On XSI-conformant > systems > the value of {TMP_MAX} is at least 10,000 [shadeoff] > (xbd) > Page: 359 Line: 11988 Section: stdio.h > Problem: > The type fpos_t must not be an array type. > Action: > Change "Type" to "A non-array type". > Add to the CH. > The description of the fpos_t type is now explicitly updated > to exclude array types, this is for alignment with the > ISO/IEC 9899:1999 standard. > (xbd) > Page: 440 Line: 14765 Section: _POSIX_SAVED_IDS > Problem: > I can parse "a, b, and c have property p, q, and r, respectively" > but cannot parse "a, b, and c have property p and q, respectively". > Still under _POSIX_SAVED_IDS it is written: > Each process has a saved set-user-ID and a saved set-group-ID. > The behavior of the setuid( ), setgid( ), and kill( ) functions > shall be dependent on the values of the saved set-user-ID and > the saved get-group-ID [sic], respectively. This is always set > to a value greater than zero. > Action: > At least the typo must be corrected. > Write something like: > The behavior of the setuid( ) and kill( ) functions > shall be dependent on the value of the saved set-user-ID. > The behavior of the setgid( ) function > shall be dependent on the value of the saved set-group-ID. > (xsh) > Page: 511 Line: 618 Section: 2.1 > [prindle.xsh-4] > Problem: > This section (beginning on this line) is the first use of the undefined > term > "library function". I believe this was intended to mean any function > defined > by this standard, or by an implementor as an extension to this standard. > I do not believe it applies to functions in general, such as those > supplied in > a third-party library, or those that are part of an application. Likewise > for > the (rare) occurrences outside this section. > Action: > Change "library function" to "function" on > page 511 lines 618, 622,625,630 > page 595 line 3705 > XCUd4 page 2428 line 8279 > XCUd4 page 2431 line 8385 > (xsh) > Page: 520 Line: 948-949 Section: 2.2.2 > Problem: > This paragraph overrides all of the prior tables except for the > unnumbered table > on page 517-518, and then only the reserved for future use functions. > Action: > delete lines 905-947 > (xsh) > Page: 520 Line: 955-957 Section: 2.2.2 > Problem: > I do not believe this paragraph is true unless XSI extensions are enabled > (i.e. > an optional header such as in XSI is a required header in > POSIX, > and may define types required by the subsequent header). > Action: > Add description of size_t to regex.h in XBD (is declared > as described in ). > (xsh) > Page: 526 Line: 1226 Section: 2.3 > Problem: > There are two quite different definitions of this error given on the same > line. I believe (given that the strerror() of EPROTOTYPE is "Protocol > wrong > type for socket" in several implementations) the first if incorrect, and > the > second is correct. > To me, "Socket type not supported" means not supported at all, i.e. by > the > implementation. > Action: > Change this line to: > Protocol wrong type for socket. The socket type is not supported by the > protocol. > Fix comment on corresponding line in in XBD to include the > first part > of this def. > (xsh) > Page: 546 Line: 2000-2001 Section: 2.8.4 > Problem: > (process scheduling) > The second sentence in this paragraph can be misread to mean that a > runnable > thread with priority x can be on a thread list for priority y. > Action: > Change: > Any runnable thread may be on any thread list. > to: > Any runnable thread may be on any thread list for that thread's > priority. > (xsh) > Page: 555 Line: 2302 Section: 2.9.4 > Problem: > This entire section is dependent on the Thread Execution Scheduling > option TPS. > Action: > Add after this line: > The functionality described in this section is dependent on support of > the > Thread Execution Scheduling option (and the rest of this section is not > further shaded for this option). > Shade and mark with margin code TPS. > Delete lines 2304-2305, which are now redundant. > (xsh) > Page: 595 Line: 3704-3707 Section: abort() > Problem: > This app-usage needs rework as it > conflicts with normative text (i.e. regarding overriding ignoring), and > references a discussion of SIGABRT that is non-existent. > Action: > delete line 3305- > "If SIGABRT is neither caught nor ignored, then the actions associated > with SIGABRT defined in Section 2.4.1 (on page 528) will be taken." > Change "library functions" to "functions" on line 3305 > (xsh) > Page: 621 Line: 4477 Section: alarm() > Problem: > This is an XSI extension. > Action: > Shade and mark XSI. > (xsh) > Page: 635 Line: 4835 Section: atexit() > Problem: > The text that is shaded and marked CX on this page does not appear to > be an extension to ISO C. However, the exact ISO C semantics are not > exactly what is shown here. The exact ISO C semantics are correctly > quoted in exit(), and should be used here too. > Action: > Remove shading, and replace "in the reverse order of their registration" > with: > "in the reverse order of their registration, except that a function is > called > after any previously registered functions that had already been called at > the > time it was registered". > also add to the CH: > The description is updated for alignment with ISO/IEC 9899:1999. > (xsh) > Page: 700 Line: 6845 Section: clock_nanosleep > Problem: > clock_nanosleep() should be labelled as "(REALTIME)" > Action: > Mark this > ADVANCED REALTIME, > (xsh) > Page: 773 Line: 9154 Section: endnetent() > Problem: > See also page 773 line 9157-9158 > See also page 773 line 9159-9160 > See also page 775 line 9207-9208 > See also page 775 line 9210-9211 > See also page 775 line 9212-9213 > See also page 779 line 9329-9330 > See also page 779 line 9333 > See also page 779 line 9337 > See also page 771 line 9107-9109 > See also page 1013 line 17048 > See also page 1013 line 17052 > All these functions do basically the same thing. Yet some say "opening a > connection to the database if necessary" and some say "opening and > closing a > connection to the database as necessary". Well, which is it? If no > connection > is open, one is opened - that is clear; but if it is opened, is it > closed? > That is terribly inconsistent among these lines, and even between > essentially > parallel functions. > Action: > change phrasing on > page 773, line 9154,9159 > page 775, line 9207,9211 > page 779, line 9329,9333 > page 1013, line 17048,17052 to > "opening and closing a connection to the database as necessary" > (xsh) > Page: 794 Line: 9796 Section: exec > Problem: > The NULL argument should be (char *)0 > (this is a comment as this is an informative example) > Action: > Change NULL to "(char *)0" on line 9796,9802,9811, > 9813,9816,9825,9834 > (xsh) > Page: 801 Line: 10043-10044 Section: exit() > Problem: > The text that is shaded and marked CX on these lines does not appear to > be an > extension to ISO C. However, the exact ISO C semantics are not exactly > what is > shown here. > Action: > Remove shading and replace the shaded text with. > The exit() function then flushes all open streams with unwritten > buffered data, closes all open streams, and removes all files created > by tmpfile(). Finally control is returned to the host environment as > described below. > (xsh) > Page: 801 Line: 10054,10059 Section: exit() > Problem: > The wording on these two lines *appears* to say the same thing in > different words. The latter wording is ambiguous: it could be parsed > either as: > has not (set its SA_NOCLDWAIT flag or set SIGCHLD to SIG_IGN) > or as: > has (not set its SA_NOCLDWAIT flag) or (set SIGCHLD to SIG_IGN) > The existence of the bullet point at line 10066 implies the former, but > it's not very clear. > Action: > Change "and has not set its SA_NOCLDWAIT > flag, or set SIGCHLD to SIG_IGN" on XSH6 draft 4, P801, L10058-10059 to > "and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to SIG_IGN". > (xsh) > Page: 803 Line: 10117 Section: exit > Problem: > "different" than what? It looks as if this text was placeed out of > context at some point. This is as it appears in the -1990 standard, > so that move was a LONG time ago. > Action: > I don't see any loss in just removing "different". > (xsh) > Page: 804 Line: 10151-10153 Section: exit() > Problem: > Reaching the end of the main() function is not equivalent to using > exit(), and the bit about "with an unspecified value" is wrong. The > actual wording of C99 is: > If the return type of the main function is a type > compatible with int, a return from the initial call to the > main function is equivalent to calling the exit function > with the value returned by the main function as its > argument;[*] reaching the } that terminates the main > function returns a value of 0. If the return type is not > compatible with int, the termination status returned to the > host environment is unspecified. > [*] In accordance with 6.2.4, the lifetimes of objects with > automatic storage duration declared in main will have > ended in the former case, even where they would not have > in the latter. > Action: > Change this wording to: > As required by the ISO C standard, using return from main() has the > same behaviour (other than with respect to language scope issues) as > calling exit() with the returned value. Reaching the end of the > main() has the same behaviour as calling exit(0). > (xsh) > Page: 836 Line: 11212-11214 Section: fdopen() > Problem: > This sentence of rationale is contradictory to the text as modified in > this > revision. > Action: > Change "There is no need... 200x." to "The mode argument formats that > include > a b are allowed for consistency with the ISO C function fopen(). The b > has > no effect on the resulting stream." > (xsh) > Page: 857 Line: 11765 Section: fgetc() > Problem: > The word "character" on this line (in the context "next character") > should be > "byte", to match the "next byte" later in the line. > Action: > Change "character" to "byte". > (xsh) > Page: 857 Line: 11765 Section: fgetc() > Problem: > The parenthesized "(if present)" is redundant. It is also not in ISO C. > Action: > Remove it. > (xsh) > Page: 857 Line: 11765 Section: fgetc() > [Annotation to [prindle.xsh-40]] > Problem: > The word "character" on this line (in the context "next character") > should > be > "byte", to match the "next byte" later in the line. > Prindle's proposed action: > Change "character" to "byte". > Action: > In addition, emphasize the change by adding a sentence to the paragraph > ending at line 11767, "Because fgetc() operates on bytes, reading a > character consisting of multiple bytes [or "a multi-byte character"] may > require multiple calls to fgetc()." > (xsh) > Page: 899 Line: 13195-13197 Section: fprintf > Problem: > The decimal conversions for which the ' flag applies should include %F > (added in C99) since they include %f. > Action: > Change "%f" to "%f, %F". > (xsh) > Page: 917 Line: 13886-13898 Section: fread() > Problem: > See also page 973 line 15747-15757 section fwrite() > The term "member(s)" is used to refer to and individual item in an array. > This is the incorrect term. Member refers to an item in a structure. > Element > refers to an item in an array. ISO C has it correct. Of course, ISO C > also > uses the variable name "nmemb" for the argument, very misleading; our > nitems > is better, though nobjects or nelements would have been even better. > N.B.: Member is used correctly on 13919/15766, because here it is > referring to > the non-portability of strucure organization. > Action: > Change all occurences of "member" on these lines to "element". Likewise > "members" -> "elements". > (lines are 13886-13898,15747-15757) > (xsh) > Page: 917 Line: 13887-13888 Section: fread() > Problem: > The wording is unclear > Action: > Change "calls are made to the" to "calls shall be made to the" to > make the requirement more explicit > (xsh) > Page: 923 Line: 14113 Section: freeaddrinfo() > Problem: > See also page 1033 line 17655 section getnameinfo() > See also page 1016 line 17166 section gethostbyaddr() > gai_strerror() should be in the SEE ALSO list. > Action: > Add gai_strerror() to the SEE ALSO list on each of the referenced pages. > (xsh) > Page: 926 Line: 14136 Section: freopen() > Problem: > The wording re: file and descriptor needs reworking. > Action: > Change "file" to "file descriptor" on 14137 > Add CH > The DESCRIPTION is updated regarding failure to close > changing the "file" to "file descriptor". > (xsh) > Page: 932 Line: 14343 Section: fscanf > Problem: > (fscanf(): character) > The term is defined (XBD6d4, P73, L2181-2186) to be a synonym > for "form-feed character". Therefore, the phrase " character" > expands to "form-feed character character". > Note that other changes are needed here as well! > Action: > Change "(, , , , or > characters);" on P932, L14343 to "(s, s, s, > tab>s, or s);". > (xsh) > Page: 944 Line: 14789-14791 Section: fstat() > Problem: > This paragraph is in conflict with the two shaded paragraphs above it. > Action: > Move this paragraph up to immediately after line 14786, and change "all > file types" to "all other file types". > (xsh) > Page: 954 Line: 15107,15113 Section: ftime() > Problem: > This legacy function fails to suggest clock_gettime() as an alternative. > Action: > Add to end of line 15107: "Realtime applications should use > clock_gettime() to > determine the current time instead of ftime()." > Add clock_gettime() to list of see-also's on line 15113 > (xsh) > Page: 967 Line: 15517 Section: fwprintf > Problem: > As with rdvk#1 for fprintf, %'F should be allowed for fwprintf since %'f > is. > Action: > Change "%f" to "%f, %F". > (xsh) > Page: 975 Line: 15825-15826 Section: fwscanf > Problem: > (fwscanf(): character) > The term is defined (XBD6d4, P73, L2181-2186) to be a synonym > for "form-feed character". Therefore, the phrase " character" > expands to "form-feed character character". > Note that other changes are needed here as well! > Action: > Change "(, , , , or > characters);" on P975, L15825-15826 to "(s, s, s, > s, or s);". > (xsh) > Page: 981 Line: 16048-16052 Section: gai_strerror() > Problem: > The text here is not terribly explicit about which values listed in > . > I'm assuming only error values are valid, and I'm also assuming that both > the > set of errors {HOST_NOT_FOUND, NO_DATA, NO_RECOVERY, TRY_AGAIN} as well > as > the set of errors {EAI_*} are handled correctly by this function, in > spite of > its name. > Action: > To avoid all confusion, because defines lots of kinds of > values, > enumerate here exactly the set of valid values (from ) for > ecode. > (xsh) > Page: 1011 Line: 16976 Section: getgroups > Problem: > getgroups returns the number of supplementary group IDs > and possibly also the effective group ID. > Thus, the value returned can be at most NGROUPS_MAX+1 > as also stated in line 16957. However, line 16976 > shows a malloc for one item less. > Action: > Change line 16975 into > ngroups_max = sysconf(_SC_NGROUPS_MAX) + 1; > (xsh) > Page: 1044 Line: 17987-17988 Section: getpgrp() > Problem: > Incorrect historical assertion in rationale. > Action: > Change "has been omitted from this...200x" to "is provided by the XSI > extension > getpgid()" > Note that getpgid() is already in the SEE ALSO list, so need not be added > there. > (xsh) > Page: 1076 Line: 18850 Section: getsubopt() > Problem: > See also page 1005 line 16767-16768 section getgrgid() > See also page 1008 line 16864-16865 section getgrnam() > See also page 921 line 13988-13989 section freeaddrinfo() *FIX IN HEADER > ONLY* > See also page 1013 line 17031-17032 section gethostbyaddr() > See also page 1032 line 17587-17589 section getnameinfo() *FIX IN HEADER > ONLY* > See also page 1055 line 18216-18217 section getpwnam() > See also page 1058 line 18323-18324 section getpwuid() > See also page 1481 line 30966-30968 section pselect() > See also page 1481 line 30969-30971 section pselect() *FIX IN HEADER > ONLY* > See also page 1042 line 17897 section getpeername() *last argument* > See also page 1072 line 18688 section getsockname() *last argument* > See also page 700 line 6849 section clock_nanosleep() > See also page 740 line 8127 section ctime() > See also page 1429 line 29577-29582 section > posix_trace_attr_getclockres() > See also page 1431 line 29640-29651 section > posix_trace_attr_getinherited() > See also page 1434 line 29752-29767 section posix_trace_attr_getlogsize() > See also page 1442 line 29962-29965 section posix_trace_create() > See also page 1446 line 30128-30129 section posix_tace_event() > See also page 1448 line 30206-30207 section posix_trace_eventid_equal() > See also page 1450 line 30293-30294 section posix_trace_eventset_add() > See also page 1452 line 30350-30351 section > posix_trace_eventtypelist_getnext_id() > See also page 1460 line 30522-30531 section posix_trace_getnext_event() > Action: > Add the restrict qualifier to each of the pointer arguments passed on the > lines noted above. Fix the header page too (in some cases above, only the > header page need be fixed). Fix the prototype also if/where it appears on > a > pointer page pointing back to the pages noted above. > (xsh) > Page: 1088 Line: 19265 Section: glob() > Problem: > On the freeaddrinfo() page, you've set a precedent (and elsewhere, I've > seen > it but just can't remember) of enumerating the [non-errno] error codes > returned > in the ERRORS section, and showing their meanings. You should do the same > her, as to say "no errors are defined" is misleading. Furthermore, unless > you > do this, the set of values that may be returned is not well defined, as > there > are other non-zero constants defined in that are not error > codes. > Action: > Replace this line with: > The glob() function shall fail and return the corresponding value if: > [GLOB_ABORTED] The scan was stopped because GLOB_ERR was set or > (*errfunc)() > returned non-zero. > [GLOB_NOMATCH] The pattern does not match any existing path name, and > GLOB_NOCHECK was not set in flags. > [GLOB_NOSPACE] An attempt to allocate memory failed. > [GLOB_NOSYS] Reserved > (xsh) > Page: 1087 Line: 40430-40433 Section: setlocale() > Problem: > The current example of a locale name is out-of-date and partially > inaccurate. The text reads: > setlocale(LC_ALL, "Fr_FR.8859"); > In this example, all categories of the international environment are > set to the locale corresponding to the string "Fr_FR.8859", or to the > French language as spoken in France using the ISO/IEC 8859-1:1998 > standard codeset. > Common practice is to follow ISO 639 for language codes, and they > use two lowercase letters (i.e., "fr" rather than "Fr"). Also, > although there is no agreement on ways to specify codesets, I > am not aware of *any* implementation that uses only "8859" to > refer to ISO/IEC 8859-1. Because that standard contains so many > commonly-used parts, a locale name would always include the part > number in some way. It might be "8859-1" or "88591" or "ISO8859-1" > or something similar, but never just "8859". > Action: > Change the text as follows: > setlocale(LC_ALL, "ISO-8859-1"); > In this example, all categories of the international environment are > set to the locale corresponding to the string "ISO-8859-1", or > to the French language as spoken in France using the ISO/IEC > 8859-1:1998 > standard codeset. > (xsh) > Page: 1114 Line: 20074 Section: inet_addr() > Problem: > The standard text not requiring inet_ntoa() to be thread-safe is missing. > This > function is properly included in the front-matter table. > Action: > Add after this line: > The inet_ntoa() function need not be reentrant. A function that is not > required > to be reentrant is not required to be thread-safe. > (xsh) > Page: 1224 Line: 23522 Section: localtime() > Problem: > The function gettimeofday() returns an int and deals with no static > object. > It seems unreasonable that a call to gettimeofday() be allowed to > overwrite > information returned by the other functions. It is, in fact, a > thread-safe > function. > Action: > Remove gettimeofday() from this list, as it does (or should) not do what > this > line says it does. > (xsh) > Page: 1236 Line: 23898-23924 Section: longjmp() > Problem: > setjmp can be either a macro or a function > Action: > Change "the setjmp() macro" on line 23903 to just "setjmp()". > (xsh) > Page: 1236 Line: 23915-23918 Section: longjmp() > Problem: > I cannot find anywhere in ISO C where this "more async safe" behavior is > specified. As fallout from ISO C 7.1.4 paragraph 4, and without an > exception > to the contrary for longjmp(), ISO C's longjmp() does not appear to be > async > safe. The fact that we've required it to be so down to the first level of > nesting would appear to be an extension. > Action: > Shade this paragraph and margin code CX. > (xsh) > Page: 1345 Line: 27278 Section: nice() > Problem: > The SEE ALSO list should have references to 2 closely related functions. > Action: > Add getpriority() and setpriority() to the SEE ALSO list. > (xsh) > Page: 1373-1376 Line: 28050-28193 Section: poll() > Problem: > This man page needs rework so the STREAMS specific parts are > separate. > Action: > Make the following changes to poll.h to make it less STREAMS > specific, and to poll() to partition the STREAMS specific semantics. This > formalizes the concept of three classes of data for poll to read/write: > normal, priority and high-priority data which presently exist on the > poll() man page. > Note that the wording of some of these descriptions has been > aligned with that on the poll() man page. > poll.h > Change the flags for the events and revents members of the > pollfd structure: > POLLIN Data other than high-priority data may be read without > blocking > POLLRDNORM Normal Data may be read without blocking > POLLRDBAND Priority data may be read without blocking. > POLLPRI High-priority data may be read without blocking. > POLLOUT Same value as POLLWRNORM. > POLLWRNORM Normal data may be written without blocking > POLLWRBAND Priority Data may be written. > POLLERR An error has occurred (revents only). > POLLHUP Device has been disconnected (revents only). > POLLNVAL Invalid fd member (revents only). > Add at the end of this: > "The significance and semantics of normal, priority and high-priority > data are file and device-specific." > On the poll() man page: > POLLIN Data other than high-priority data may be read without > blocking . > [XSR] For STREAMS, this flag is set in revents even if the message > is of zero length. This flag shall have the same effect as > POLLRDNORM | POLLRDBAND. > POLLRDNORM Normal Data may be read without blocking > [XSR] For STREAMS, data on priority band 0 may be read without > blocking. > This flag is set in revents even if the message is of zero > length. > POLLRDBAND Priority data may be read without blocking. > [XSR] For STREAMS, data on priority bands greater than 0 may be > read without blocking. This flag is set in revents even if > the message is of zero length. > POLLPRI High-priority data may be read without blocking. > [XSR] For STREAMS, this flag is set in revents even if the message > is > of zero length. > POLLOUT Normal data may be written without blocking > [XSR] For STREAMS, data on priority band 0 may be written without > blocking. > POLLWRNORM Same as POLLOUT. > POLLWRBAND Priority Data may be written. > [XSR] For STREAMS, data on priority bands greater than 0 may be > written without blocking. This event only examines bands > that have been written to at least once. > POLLERR An error has occurred on the device or stream. This flag > is only valid in the revents bitmask; it shall be ignored > in the events bitmask. > POLLHUP The device has been disconnected. This event and POLLOUT > are mutually exclusive; a stream can never be writable if > a hangup has occurred. However this event and POLLIN, > POLLRDNORM, POLLRDBAND, or POLLPRI are not mutually-exclusive. > This flag is only valid in the revents bitmask; it shall > be ignored in the events bitmask. > POLLNVAL The specified fd value is invalid. This flag is only valid > in the revents bitmask; it shall be ignored in the > events bitmask. > Add a new para at the end of the flags: > "The significance and semantics of normal, priority and high-priority > data are file and device-specific." > (xsh) > Page: 1407 Line: 29171-29173 Section: posix_spawnattr_getflags() > [prindle.xsh-116] > Problem: > The sentence "In addition...also be supported." is redundant. The concept > is > captured immediately before with shading and margin coding. > Action: > Delete this sentence. > (xsh) > Page: 1449 Line: 30261 Section: posix_trace_eventid_equal > Problem: > The text currently says > The posix_trace_eventid_get_name( ) and posix_trace_trid_eventid_open( ) > functions may fail if: | > [EINVAL] The trid argument was not a valid trace type identifier. > The trid argument is a trace stream identifier, not a trace type > identifier > Action: > Change "trace type identifier" to "trace stream identifier" > (xsh) > Page: 1460 Line: 30529 Section: posix_trace_getnext_event() > [prindle.xsh-126] > Problem: > Margin coding is incorrect. > Action: > Revert back to margin code "TRC" on this line. > (xsh) > Page: 1471 Line: 30723 Section: posix_trace_trygetnext_event() > [prindle.xsh-125] > Problem: > Margin coding is incorrect. > Action: > Change margin code from "TRC TMO" to "TRC". > (xsh) > Page: 1495 Line: 31457,31460 Section: pthread_attr_setinheritsched > Problem: > The specification, (as does POSIX 1003.1-1996), says only that the > inheritsched attribute specifies the inheritance of "the scheduling > policy and associated attributes". While I believe there is no actual > ambiguity in POSIX 1003.1-1996, given how the "associated attributes" > are defined, I'm less convinced that there's no real ambiguity in the > new format. Furthermore, it would always have been better to have the > affected attributes spelled out rather than implied. > I would like to see this page give a list of the associated standard > attributes. Those are, I believe, schedpolicy, schedparams, and > contentionscope. > In particular, I have in the past seen some confusion regarding > whether contention scope is or is not one of the inherited attributes. > Scope must be included for two reasons: > 1) Because the only definition of "thread scheduling attributes" > occurs in 1003.1-1996 on page 298, section 13.4.1, and this section > defines the schedpolicy, schedparams, and contentionscope attributes. > 2) Because many systems must place limitations (e.g., privilege) on > the policy and priority values for SYSTEM contention scope that do > not apply for PROCESS contention scope. Failing to switch between the > "explicit" and "inherited" contention scope when switching policy > and priority would result in unsupportable combinations. > This is a "comment" because while it's a little more than just an > "editorial" issue, I don't think it merits an "objection". > I am suggesting merely that the necessary interpretation be made more > clear to readers (both application developers and implementors). > Action: > Provide a new paragraph explaining the phrase "thread scheduling > attributes" (a phrase already used on lines 31458 and 31461), such > as: > The following "thread scheduling attributes" defined by the > standard are affected by the inheritsched attribute: scheduling policy > (schedpolicy), scheduling parameters (schedparams), and scheduling > contention scope (contentionscope). > With such an introduction, the phrase on lines 31457 and 31460 would > be reduced to "thread scheduling attributes". > (xsh) > Page: 1503 Line: 31643-31644 Section: pthread_attr_getstack() > Problem: > The restrict keyword wasn't added for this functions. > Action: > Replace the lines with: > int pthread_attr_getstack(const pthread_attr_t *restrict attr, > void **restrict stackaddr, > size_t *restrict stacksize); > (xsh) > Page: 1505 Line: 31704 Section: pthread_attr_setstackaddr > Problem: > With the introduction in draft for of pthread_attr_setstack, I would > prefer to see a "note" added to pthread_attr_setstackaddr directing > developers towards the new and improved interface. > This does not affect the correctness of the standard, merely its > "ease of use". > Action: > 1. Mark this man page Obsolescent (add OB to the synopsis] > 2. Add pthread_attr_setstack, pthread_attr_getstack to the SEE ALSO line > 3. Add to APPLICATION USAGE, as suggested in the rdvk > 4. Add a note to Change History that the page is now marked > obsolescent. > (xsh) > Page: 1536 Line: 32401-32421 Section: pthread_cond_broadcast > Problem: > (pthread_cond_broadcast(): rationale) > The statement on L32415: > cond->value++; /* 3 */ > cannot be executed after the statement on L32414: > pthread_mutex_lock(cond->mutex); /* 2 */ > until the code on L32403: > pthread_mutex_unlock(mutex); /* 9 */ > being executed since pthread_mutex_lock(cond->mutex) will block until > pthread_mutex_unlock(mutex) releases the mutex. > Action: > Change the example on P1536, L32401-43421 to: > pthread_cond_wait(mutex, cond): > value = cond->value; /* 1 */ > pthread_mutex_unlock(mutex); /* 2 */ > pthread_mutex_lock(cond->mutex); /* 10 */ > if (value == cond->value) { /* 11 */ > me->next_cond = cond->waiter; > cond->waiter = me; > pthread_mutex_unlock(cond->mutex); > unable_to_run(me); > } else > pthread_mutex_unlock(cond->mutex); /* 12 */ > pthread_mutex_lock(mutex); /* 13 */ > pthread_cond_signal(cond): > pthread_mutex_lock(cond->mutex); /* 3 */ > cond->value++; /* 4 */ > if (cond->waiter) { /* 5 */ > sleeper = cond->waiter; /* 6 */ > cond->waiter = sleeper->next_cond; /* 7 */ > able_to_run(sleeper); /* 8 */ > } > pthread_mutex_unlock(cond->mutex); /* 9 */ > (xsh) > Page: 1553 Line: 32898-32899 Section: pthread_condattr_getpshared() > [prindle.xsh-131] > Problem: > This paragraph is out of context, and is incorrect in this context, since > it > ignores the clock attribute. The paragraph correctly appears on page > 1549, but > is incomplete there because it still lacks sufficient context. > Action: > Delete this paragraph here. Insert this sentence before lines 32801-32802 > on > page 1549: > This volume of xxx requires two attributes, the clock attribute and the > process-shared attribute. [clock and process-shared in italics] > (xsh) > Page: 1564 Line: 33170 Section: pthread_exit() > Problem: > The pthread_exit() function obviously must never return which is > also stated in line 33167. But why is then the sentence in line > 33170 necessary which says > The pthread_exit() function shall not return an error code of > EINTR. > Action: > delete line 33170 > Change "cannot" to "shall not" on line 33167 > (xsh) > Page: 1571 Line: 33384-33386 Section: pthread_getspecific() > [prindle.xsh-133] > Problem: > There is no indication in the change history of the interpretation that > supports > this requirement (which is not in 1003.1-1996). > Action: > Document the source of this new requirement as: > IEEE PASC Interpretation 1003.1c #3 (Part 6) is applied, updating the > DESCRIPTION. > (xsh) > Page: 1616 Line: 34735-34739 Section: pthread_once() > Problem: > I'll buy into this if it is made a "may fail". Like > pthread_getspecific(), I > think it important to allow implementations to keep this efficient, > especially > when it results in no action (in which case, it certainly wouldn't be > necessary > to determine the validity of the init_routine address). > Action: > Add the following error as a may fail > [EINVAL] Either once_control or init_routine is invalid. > delete line 34740 > Add CH > The EINVAL error is added as a may fail case for if either > argument is invalid. > (xsh) > Page: 1619 Line: 34861 Section: pthread_rwlock_destroy() > [prindle.xsh-145] > Problem: > See also all pthread_rwlock*() functions that follow, change history. > Reference is made to the RWL margin code. No additional change history > indicates > that the RWL option was moved into base threads, and the RWL margin code > no > longer exists. > Action: > Change p 1619line 34861 to > "The margin code in the SYNOPSIS is changed to THR to indicate that the > functionality is now part of the Threads option (previously it > was part of the Reader/Writer locks option in 1003.1j and also > part of the XSI extension ). The initializor macro is also > deleted from the SYNOPSIS." > Change as a separate bullet not under the > 1j specific changes : > p 1622 line 34948 > p 1629 line 35136 > p 1631 line 35189 > p 1634 line 35246 > "The margin code in the SYNOPSIS is changed to THR to indicate that the > functionality is now part of the Threads option (previously it > was part of the Reader/Writer locks option in 1003.1j and also > part of the XSI extension ). " > p 1636 l 35300 > "The margin code in the SYNOPSIS is changed to THR TSH to indicate that > the > functionality is now part of the Threads option (previously it > was part of the Reader/Writer locks option in 1003.1j and also > part of the XSI extension ). " > (xsh) > Page: 1745 Line: 38516-38518 Section: sched_setparam() > Problem: > Regarding Note to Reviewers, I see no problem with allowing SCHED_OTHER > to > utilize the ss parameters. This is consistent with the whole behavior of > setting > parameters being implementation-defined (line 38521). However, I agree > with > Donn that the wording is bad. It was fixed on line 38512, and should be > here > too. > Action: > Change the last sentence of the previous pagagraph (38513-38515) to: > "If the scheduling policy of this process is not SCHED_FIFO, SCHED_RR, or > SCHED_SPORADIC, the effects of these members is implementation-defined; > this > case includes the SCHED_OTHER policy." > (xsh) > Page: 1806 Line: 40392-40395 Section: setlocale > Problem: > (setlocale(): rationale) > This list doesn't give any indication that LC_MONETARY and LC_MESSAGES > are > affected by the environment. > Action: > Add the following after P1806, L40395: > 5. Monetary formatting > 6. Messaging > (xsh) > Page: 1806 Line: 40393 Section: setlocale > Problem: > (setlocale(): rationale) > String handling includes a lot more than just collating, but it looks > like > you really do mean collating (as in LC_COLLATE) here. > Action: > Change "String handling (that is, collating)" on P1806, L40393 to > "Collating". > (xsh) > Page: 1807 Line: 40421-40422 Section: setlocale > Problem: > (setlocale(): rationale) > There is no requirement that setlocale() return a pointer to a static > area. > (It is allowed, but not required.) > Action: > Change "is a pointer to a static area" on P1807, L40421-40422 to "may be > a > pointer to a static area". > (xsh) > Page: 1807 Line: 40442-40443 Section: setlocale > Problem: > (setlocale(): rationale) > This is true for XSI-conforming systems too. > Action: > Change "For POSIX-conforming systems, this" on P1807, L40442-40443 to > "This". > (xsh) > Page: 1872-1873 Line: 42311-42340 Section: signal() > Problem: > There are just enough minor deviations in the text here from the text in > ISO C > (including at least the omission of SIGILL and SIGSEGV references, and a > glitch near line 42333 which redundantly repeats a requirement) that it > would > be worthwhile just to replace this entire line range with the text from > ISO C > suitable re-formatted and with the few reference changes to make it > consistent > with this document. I won't include all that text here, since copying it > twice > is twice as likely to get it wrong. Just take it from ISO C. > Action: > Rework this text to align with the c99 wording. > (xsh) > Page: 1898 Line: 43058 Section: sleep() > Problem: > delete the words "because of premature arousal" and rework as per .1-1996 > Action: > as per problem > (xsh) > Page: 1914 Line: 43447 Section: stat() > Problem: > I have seen the ballot comment from Andries Brouwer saying: "An off_t is > printed with a %9ld format, but it may be larger than what fits into a > long." > I agree with his concern, but disagree with his proposed action. > The example that contains this printf() prints several fields. This is > the > only only one that doesn't have an explicit space to separate the output > from > the previous field where the results would cause an ambiguity. > Therefore, even > going from ``%9ld'' to ``"%12" PRIdMAX'' doesn't guarantee that a group > name > from the previous printf() won't run into the size field from this > printf(). > Furthermore, the definition of PRIdMAX doesn't appear in any of the > headers > currently listed in this example. (It appears in .) And, > intmax_t > isn't defined in any of the headers in this example either. (It appears > in > .) And, examples using printf() should include . > Some e-mail discussions on this topic have suggested using the ``j'' > length > modifier with the ``d'' conversion specifier instead of ``PRIdMAX'', but > they > have still missed the need for a leading space in the format and for > inclusion > of . > Also note that the file systems I most often work with now can have a > sparse > files with sizes well over 999,999,999,999 bytes in length. Adding a > leading > space to the format removes any ambiguity that might be caused by filling > the > field width without reserving extra space in the output for the small > number of > files that have sizes larger than 999,999,999 bytes. Using 12 instead of > 9 > doesn't solve this problem by itself. > Action: > Add after P1913, L43420: > #include > #include > Change P1914, L43447 from: > printf("%9ld", statbuf.st_size); > to: > printf(" %9jd", (intmax_t)statbuf.st_size); > [Ed note: statbuf.st_gid was corrected to statbuf.st_size in the > code above] > (xsh) > Page: 1993 Line: 46029 Section: system() > Problem: > I doubt the .1a alignment happened in Issue 4, since .1a was integrated > only > recently. > Action: > Add header showing where Issue 6 changes start. > (xsh) > Page: 2129 Line: 50120 Section: wcstod > Problem: > (wcstod(): change history) > The Issue 6 change history on P2129, L50121-50122 says the return value > section has been updated extensively. Although this is true, since the > return value for the underflow case is incompatible with C89, > POSIX.1-1996, > and SUSv2; the difference shoould be explained more fully. > Action: > Add a new bullet to the list after P2129, L50120: > If the correct value for wcstod() would cause underflow, the return > value > changed from 0 (as specified in Issue 5) to the smallest normalized > positive number. > (xsh) > Page: 2165 Line: 51262-51264 Section: write() > Problem: > See also page 1681 line 36422-36423 section read() > These statements are incomplete due to the addition of XSI functions. > Action: > Add > --- > SHM XSI If fildes refers to a shared memory type, the result > of the writev() or pwrite() functions is unspecified. > TYM XSI If fildes refers to a typed memory type, the result > of the writev() or pwrite() functions is unspecified. > Similarly on p 1681, changing writev()-> readv() and pwrite() -> pread() > (xcu) > Page: 0 Line: 0 Section: (various) > Problem: > For most utilities (e.g. at lines 4819-4821 for admin) it is > specified that the implementation-defined default locale shall be > used if one of the LC_* variables has an invalid setting. This is > contradicted in the other documents. > Action: > Change the first sentence to now read: > This section describes environment variables that are relevant to the > operation of internationalized interfaces described in > IEEE Std. 1003.1-200x. > Line 5962 change "shall" to "can". > After 5965 add: > "The use of the I18N variables by utilities described in the Shell and > Utilities vol of this std are described in the environment variables > section for those utilities in addition to the global effects > described in this section." > Change the LANG definition on all the utility pages in XCU to > LANG Provide a default value for the internationalization > variables that are unset or null. (See the Base > Definitions volume of IEEE Std 1003.1-200x, Section 8.2 > for the precedence of internationalization variables > used to determine the values of locale categories.) > (xcu) > Page: 2249 Line: 1638 Section: 2.6.5 > Problem: > (field splitting: character) > The term is defined (XBD6d4, P82, L2390-2394) to be a synonym > for > "newline character". Therefore, the phrase " character" expands > to > "newline character character". > Note that other changes are needed here as well! > Action: > Change ", , or characters" on P2249, L1638 to > "s, s, or s". > (xcu) > Page: 2265 Line: 2176 Section: 2.10 > Problem: > 80 bytes; in a 2-byte multibyte character set, or in Unicode, this > is 40 characters. For a 4-byte code (full 10646) this is 20 characters. > I understand that this is an implementation limit, but in an > internationalized > context this becomes a fairly significant limit. > Also, in what locale is this interpreted? In particular, if there are > multiple locales where the representation of the portable filename > character set varies, in which locale is this interpreted. (Remember, > this is happening in the kernel, not user space, so the concept of > locale gets a lot spookier to deal with.) (Is it required to be > "in the character set of the filesystem", even if not operating > in a compataible locale.) (All other locale issues can be hidden > by wrappers, but this can't be because it's, like executable files > in general, handled directly by the OS.) > (Consider, for example, an OS that names files in (8-bit) 646 like > characters, but with a locale set for Unicode (so the, for example, > awk program is written in Unicode). How does the user create a > file where the first few bytes are in 646 (not even the first line, > because the arguments are in Unicode). Also consider that many > (most?) Unicode files themselves begin with a feff or ffef flag word.) > Action: > Delete the section. > (xcu) > Page: 2266 Line: 2212 Section: 2.11.2 > Problem: > This is an odd usage of "shall". Originally most of this paragraph > was rationale (and it used the word was "must"; it made sense then). In > normative text, however, "must" isn't allowed, but this "shall" > appears to require that if a reserved word is permitted, it shall > be used (thus the only legal shell scripts are those which contain > only if, while, and the like statements). > Action: > Delete lines 2206-2212 from "This rule applies ...". > The text is duplicated in rationale, see page 3542 > (xcu) > Page: 2349 Line: 5021 Section: ar > Problem: > (ar: -q option) > The rationale on P2352, L5168-5172 state that "quickly" need not remain > true > for the ar utility -q option, but "quickly" still appears in the > description > of the -q option. > Action: > Change "Quickly append" on P2349, L5021 to "Append". > (xcu) > Page: 2350,2530,2775,2796,2920,2961,2975-3020,3265 Line: > 5082,12169,21596,22451,27327,29066, Section: > ar,diff,lp,mailx,pax,ps,qalter...,who > Problem: > In general, if a utility is affected by LC_TIME then it should also be > affected by the TZ environment variable. This is not always stated. > (I believe that, exceptionally, the 'patch' utility is not affected by > TZ.) > While checking this, I also noticed these inconsistencies: > Line 12169 (diff) says TZ determines a locale - most utilities (e.g. > date and ls) say it determines a timezone. > The rational at line 23237 (mailx) says the words "may affect" are > used, but they are not used. > Lines 29626-31335 (qalter-qsub) say "If the TZ variable is not set, > an unspecified system default timezone is used" - other utilities do > not bother to say this. > Action: > ar: > Add new entry after P2350, L5085: > TZ Determine the timezone used to calculate date and time > strings written by ar -tv. If TZ is unset or null, an > unspecified default timezone shall be used. > add CH: The TZ entry is added to the ENVIRONMENT VARIABLES section] > date: > Change "not set" on P2508, L11294 to "unset or null". > Change "not set" on P2511, L11410 to "unset or null". > diff: > Delete " the locale for affecting" from P2530, L12169. > Add new sentence to end of P2530, L12170: > If TZ is unset or null, an unspecified default timezone shall be > used. > ipcs: > Change: > time strings written by ipcs. > on P2724, L19603 to: > date and time strings written by ipcs. If TZ is unset or null, > an unspecified default timezone shall be used. > lp: > Add new entry after P2776, L21607: > TZ Determine the timezone used to calculate date and time > strings displayed in the lp banner page, if any. If TZ > is unset or null, an unspecified default timezone shall > be used. > add CH: The TZ entry is added to the ENVIRONMENT VARIABLES section] > ls: > Add new sentence to end of P2781, L21846: > If TZ is unset or null, an unspecified default timezone shall be > used. > mailx: > Add new entry after P2797, L22488: > TZ This variable may determine the timezone used to > calculate date and time strings written by mailx. If TZ > is unset or null, an unspecified default timezone shall > be used. > add CH: The TZ entry is added to the ENVIRONMENT VARIABLES section] > pax: > Add new entry after P2920, L27332: > TZ Determine the timezone used to calculate date and time > strings when the -v option is specified. If TZ is unset > or null, an unspecified default timezone shall be used. > add CH: The TZ entry is added to the ENVIRONMENT VARIABLES section] > pr: > Change: > for use in writing header lines. > on P2947, L28487 to: > used to calculate date and time strings written in header lines. > If TZ is unset or null, an unspecified default timezone shall be > used. > ps: > Add new entry after P2961, L29066: > TZ Determine the timezone used to calculate date and time > strings displayed. If TZ is unset or null, an > unspecified default timezone shall be used. > add CH: The TZ entry is added to the ENVIRONMENT VARIABLES section] > qalter: > Delete P2975, L29624. > Change P2975, L29626-29627 to: > TZ Determine the timezone used to interpret the date-time > option-argument. If TZ is unset or null, an unspecified > default timezone shall be used. > comment add CH: The TZ entry is added to the ENVIRONMENT VARIABLES > section] > qdel: > Delete P2927, L29762. > Delete P2979, L29764-29765. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > qhold: > Delete P2982, L29889. > Delete P2982, L29891-29892. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > qmove: > Delete P2985, L29982. > Delete P2985, L29984-2998 > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > qmsg: > Delete P2988, L30087. > Delete P2988, L30089-30090. > qrerun: > Delete P2991, L30182. > Delete P2991, L30184-30185. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > qrls: > Delete P2993, L30294. > Delete P2993, L30296-30297. > qselect: > Change "\fIdate_time\fP on P2996, L30391 to "\fItime\fP". > Delete P3001, L30609. > Change P3001, L30611-30612 to: > TZ Determine the timezone used to interpret the date-time > option-argument. If TZ is unset or null, an unspecified > default timezone shall be used. > qsig: > Delete P3005, L30740. > Delete P3005, L30742-30743. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > qstat: > Delete P3008, L30864. > Delete P3008, L30867-30868. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > qsub: > Change "\fIdate_time\fP on P3012, L30999 to "\fItime\fP". > Delete P3020, L31328. > > Change P3020, L31334-31335 to: > TZ Determine the timezone used to interpret the date-time > option-argument. If TZ is unset or null, an unspecified > default timezone shall be used. > touch: > Add new sentence to end of P3131, L35448: > If TZ is unset or null, an unspecified default timezone shall be > used. > uucp: > Delete P3180, L37156. > Delete P3180, L37158. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > uustat: > Delete P3191, L37544. > Delete P3191, L37546. > comment add CH: The LC_TIME and TZ entries are removed from the > ENVIRONMENT > VARIABLES section] > who: > Add new entry after P3265, L40387: > TZ Determine the timezone used when writing date and time > information. If TZ is unset or null, an unspecified > default timezone shall be used. > Add to CH after P3267, L40447: > The TZ entry is added to the ENVIRONMENT VARIABLES section. > (xcu) > Page: 2427 Line: 8257 Section: c99 > Problem: > Wording needs clarification > Action: > add "completely" to sentence on page 2227, > line 878 ("... completely describes the standard output ..."). > Similarly for OUTPUT FILE, line 919, add "completely" ("...completely > describes ...") Also add reviewers notes here (p 2227) asking everyone > to check the stdout/output files section of every command/utility. > (xcu) > Page: 2447 Line: 8986 Section: chgrp > Problem: > The Rationale (A.3 under symbolic link) says: > "The fourth domain is symbolic links referencing files of type directory, > specified to utilities that are performing a traversal of a file > hierarchy. > (This includes symbolic links specified as command line file name > arguments > or encountered during the traversal.)" > "All standard utilities do not, by default, indirect into the file > hierarchy > referenced by the symbolic link." > However, the description of the chgrp utility (XCU, p. 2447 line 8986) > says: > "Unless a -H, -L, or -P option is specified, it is unspecified which of > these > options will be used as the default." > These contradict each other. > Action: > fixup rationale at > page 3336 line 1022 change first word "All" to "Most". > (xcu) > Page: 2465 Line: 9667 Section: cmp > Problem: > (cmp: shall) > A conversion from declarative text to "shall" was missed. > Action: > Change "writes no" on P2465, L9667 to "shall write no". > (xcu) > Page: 2471 Line: 9894,9908,9922 Section: command > Problem: > The description of "command" does not make it clear that when -v or -V is > used, the specified command_name is not executed. > I.e. a possible interpretation of the current description is that: > > command -v some_command > > first writes the path name for some_command to stdout and then executes > some_command. I don't know of any implementations that have interpreted > it this way, but it needs to be clarified. > Action: > On line 9894 change "the effect of command shall be the same as omitting > command" to "the effect of command (with no options) shall be the same > as omitting command". > On line 9908 after "to invoke command_name" add ", but do not invoke > command_name". > On line 9922 after "(see Section 2.13 (on page 2273))" add ", but do > not invoke command_name". > (xcu) > Page: 2531 Line: 12194 Section: diff > Problem: > (diff: shall) > A conversion from declarative text to "shall" was missed. > Action: > Change "section are" on P2531, L12194 to "section shall be". > (xcu) > Page: 2603 Line: 15048-15049 Section: ex > Problem: > (ex: character) > The term is defined (XBD6d4, P73, L2181-2186) to be a synonym > for "form-feed character". Therefore, the phrase " character" > expands to "form-feed character character". > Note that other changes are needed here as well! > Action: > Change ", , and characters," on P2603, L15048- > 15049 to "s, s, and s,". > (xcu) > Page: 2637 Line: 16413 Section: expand > Problem: > (expand: character) > The term is defined (XBD6d4, P101, L2843-2846) to be a synonym > for > "space character". Therefore, the phrase " character" expands to > "space character character". > Note that other changes are needed here as well! > Action: > Change " and characters," on P2637, L16413 to "s and > s,". > (xcu) > Page: 2669 Line: 17581 Section: fold > Problem: > (fold: character) > The term is defined (XBD6d4, P107, L3007-3013) to be a synonym for > "tab character". Therefore, the phrase " character" expands to "tab > character character". > Note that other changes are needed here as well! > Action: > Change "the , , or characters" on > P2669, > L17581 to "s, s, or s". > (xcu) > Page: 2697 Line: 18658 Section: getconf > Problem: > (getconf: missing change history) > There should be a note in the change history pointing out that the XBS5* > system_var values (P2694, L18525-18540) have been marked LEGACY. > Action: > Add new paragraph after P2693, L18658: > XSI marked system_var (XBS5_*) values are marked LEGACY in this issue. > (xcu) > Page: 2719 Line: 19417 Section: id > Problem: > (id: shall) > A conversion from declarative text to "shall" was missed. > Action: > Change "argument is omitted" on P2891, L26139 to "argument shall be > omitted". > (xcu) > Page: 2742 Line: 20286 Section: kill > Problem: > The wording is unclear. > Action: > In parts of 1003.2-1992 it states that ps is excluded although it > is present. This rationale was carried forward and lines > 20286-20287 should be deleted > (xcu) > Page: 2748 Line: 20555 Section: lex > Problem: > I ran across an alternative to this problem just a little earlier, > see line 20491. I believe that a Note is still required, but that > the solution in 20491 is more useful. > Action: > Change to > Note: If a \x sequence needs to be immetiately followed by a hexadecimal > digit character, a sequence such as "\x1""1" can be used, which > represents > a character containing the value 1, followed by the character '1'. > (xcu) > Page: 2788 Line: 22125 Section: m4 > Problem: > (m4: character) > The term is defined (XBD6d4, P82, L2390-2394) to be a synonym > for > "newline character". Therefore, the phrase " character" expands > to > "newline character character". > Note that other changes are needed here as well! > Action: > Change "trailing and characters," on P2788, L22125 to > "trailing s and s,". > (xcu) > Page: 2803 Line: 22773 Section: mailx > Problem: > (mailx: character) > The term is defined (XBD6d4, P82, L2390-2394) to be a synonym > for > "newline character". Therefore, the phrase " character" expands > to > "newline character character". > Note that other changes are needed here as well! > Action: > Change " and characters," on P2803, L22773 to "s and > s,". > (xcu) > Page: 2803 Line: 22777 Section: mailx > Problem: > (mailx: character) > The term is defined (XBD6d4, P82, L2390-2394) to be a synonym > for > "newline character". Therefore, the phrase " character" expands > to > "newline character character". > Note that other changes are needed here as well! > Action: > Change " and characters," on P2803, L22777 to "s and > s,". > (xcu) > Page: 2891 Line: 26122 Section: od > Problem: > (od: shall) > A conversion from declarative text to "shall" was missed. > Action: > Change "bytes are" on P2891, L26122 to "bytes shall be". > (xcu) > Page: 2891 Line: 26139 Section: od > Problem: > (od: shall) > A conversion from declarative text to "shall" was missed. > Action: > Change "bytes are" on P2891, L26139 to "bytes shall be". > (xcu) > Page: 3052 Line: 32411-32412 Section: sed > Problem: > In lines 32411-32412, the contrast between "Zero or more > characters" and "Any number of semicolons" raises the question of what > number of semicolons is allowed other than zero or more (a negative or > imaginary number?) > Also, can the spaces and semicolons be intermingled? Can there be > semicolons before the function if the addresses are omitted? And > although it can be assumed that the characters have no effect, > do the semicolons have an effect? > (I believe the semicolons are taken to be separators from a possible > previous command and therefore have no effect). > (Lines 32474-32490 use various styles of wording to describe the > syntax, but the contrasts there are not so obvious.) > Action: > Replace: > Zero or more characters shall be accepted before the first > address and before function. Any number of semicolons shall be > accepted before the first address. > by: > The command can be preceded by characters and/or semicolons. > The function can be preceded by characters. These optional > characters have no effect. > Note fix up the tokens appropriately, e.g. use s rather than > characters > (xcu) > Page: 3058 Line: 32658 Section: sed > Problem: > (sed: character) > The term is defined (XBD6d4, P101, L2843-2846) to be a synonym > for > "space character". Therefore, the phrase " character" expands to > "space character character". > Note that other changes are needed here as well! > Action: > Change " and characters" on P3058, L32658 to "s and > s". > (xcu) > Page: 3063 Line: 32877 Section: sh > Problem: > (sh: character) > The term is defined (XBD6d4, P82, L2390-2394) to be a synonym > for > "newline character". Therefore, the phrase " character" expands > to > "newline character character". > Note that other changes are needed here as well! > Action: > Change ", , and characters." on P3063, L32877 to > "s, s, and s.". > (xcu) > Page: 3093 Line: 34058-3059 Section: strip > Problem: > (strip: rationale) > The description and the first part of the paragraph in rationale on > P3093, > L34057-34059 say that strip performs actions "similar" to the -s option > to > the compilers. The last sentence of the rationale says they are > identical. > Action: > Delete the last sentence on P3093, L34058-34059. > (xcu) > Page: 3167 Line: 36731 Section: unexpand > Problem: > (unexpand: character) > The term is defined (XBD6d4, P101, L2843-2846) to be a synonym > for > "space character". Therefore, the phrase " character" expands to > "space character character". > Note that other changes are needed here as well! > Action: > Change " and characters" on P3167, L36731 to "s and > s". > (xcu) > Page: 3202 Line: 37970 Section: vi > Problem: > (vi: character) > The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for > "blank character". Therefore, the phrase " character" expands to > "blank character character". > We also have a defined term "blank line" which matches what is being > described here. We should use the defined term. > Action: > Change "empty or character-filled lines" on P3202, L37970 to > "blank > lines". > (xcu) > Page: 3203 Line: 37984 Section: vi > Problem: > (vi: character) > The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for > "blank character". Therefore, the phrase " character" expands to > "blank character character". > We also have a defined term "blank line" which matches what is being > described here. We should use the defined term. > Action: > Change "empty or character-filled lines" on P3203, L37984 to > "blank > lines". > (xcu) > Page: 3203 Line: 38007 Section: vi > Problem: > (vi: character) > The term is defined (XBD6d4, P53, L1722-1725) to be a synonym for > "blank character". Therefore, the phrase " character" expands to > "blank character character". > We also have a defined term "blank line" which matches what is being > described here. We should use the defined term. > Action: > Change "empty or character-filled lines" on P3203, L38007 to > "blank > lines". > (xcu) > Page: 3204 Line: 38039 Section: vi > Problem: > The use of "physical" and "logical" is backwards to the conventional use > of > those terms. > Specifically: considering memory: logical memory is a simple linear > memory space. Physical memory is a mess of pages, page tables, > and representation of pieces of memory in apparently random locations > on memory and the disk. A logical file has a simple structure; > a physical file is scattered all over the place. Thus, I believe > that referring to "logical" as the actual (messy) represenation > and "physical" as the idealized representation is a disservice to the > reader. Others may disagree, but the objective of the standard > should be precision and clarity, not retaining the old words just > for the sake of retaining the old words. > Action: > For ex: > At 13685, 13688, 13693, 13695, 15196, 15247: "screen" -> "display line" > For more: > At 24711, "screen" -> "display line" > At 24807, "logical" -> "display" > At 24836, insert a paragraph break at "In the following" > (that's wholly unrelated to the rest of the paragraph, and > is very hard to find because of that). > At 24838, delete "logical" (adding "display" would be redundant) > At 24973: "physical" -> "file"; "logical" -> "display" (and see prior > mail, > once resolved). > At 24983: "physical line number" -> "line number in the file" > For ps, qstat: > At 29407, 30836: "screen" -> "display line" (but as is is OK, too) > For vi > At 38066(2x), 38070, 38071, 38074, 38075, 38076, 38078, > 38288, 38290, 39193, 39195, 39198, 39199, 39221, 39225, > 39565,: "screen" -> "display line" > At 1974 (XBD), Add > Display Line: a line of text on a physical device or an emulation > thereof. Such a line will have a maximum number of characters which > can be presented. > Note: This may also be written as "line on the display". > Add after 38018 (move and change from 38039, because it's needed sooner). > In the remainder of the description of the vi utility, the term > ``buffer line'' refers to a line in the edit buffer and the term > ``display line'' refers to the line or lines on the display screen > used to display a one buffer line. The term ''current line'' refers > to a specific ''buffer line''. > Replace 38019-38020 with > If there are display lines on the screen for which there are no > corresponding > buffer lines because they correspond to lines that would be after the end > of the file, they shall be displayed as a single tilde ('~') character. > Delete 38039-38041 > Change "logical" to "display" on: 38044, 38046, 38192, 39513 > Change "physical" to "display" on: 38068, 38071, 38072, 38075, 38076, > 38078, 38080, 39564 > (no, that's not wrong; it seems the meaning of the word physical > changed here (see in particular 39564 if you don't believe me.)) > Change "physical" to "buffer" on 38066, 39454, 39513, 39515, 39516, > 39518, 39523, 39553. > Change 39436 to read: > single line from the edit buffer (one "buffer line") was kept current at > any > time. This line was normally > Change 39532 to read: > and M) operate on display (screen) lines, not (edit) buffer lines. > Change 39540 > changing the commands to be oriented to the display (instead of oriented > to > the buffer). IEEE Std. 1003.1-200x > (xcu) > Page: 3271 Line: 40579-40580 Section: xargs > Problem: > (xargs: character) > The term is defined (XBD6d4, P82, L2390-2394) to be a synonym > for > "newline character". Therefore, the phrase " character" expands > to > "newline character character". > Note that other changes are needed here as well! > Action: > Change "non-apostrophe (''') and non- characters". on P3271, > L40579-40580 to "non-apostrophe (''') characters and non-s". > (xcu) > Page: 3274 Line: 40705 Section: xargs > Problem: > (xargs: non-English) > A "will succeed" in XCU5 was translated to "succeeds" in this draft in a > place (in application usage) that creates a non-sentence. > It looks like this was an attempt to move from future tense to present > tense, but this is describing what xargs will do (in the future) under > certain conditions. > Action: > Change "further invocations using the current data stream succeeds" on > P3274, L40705 to "further invocations using the current data stream will > succeed". > (xcu) > Page: 3275 Line: 40738 Section: xargs > Problem: > (xargs: examples) > The terminology used in example 3 differs from that used in the other > examples. (And, there is no need to go to "shall" in the examples.) > Action: > Change the first sentence on P3275, L40738 from: > The user is asked which files in the current directory shall be > archived. > to: > In the following commands, the user is asked which files in the current > directory are to be archived. > (xcu) > Page: 3275 Line: 40749 Section: xargs > Problem: > (xargs: missing rationale) > There was an editorial note in P1003.2b draft 14 that was not applied. > Action: > Change "For example, the -e eofstr option can be replaced by features of > sed. The -i replstr" on P3275, L40766-40767 to "For example, the -i > replstr". > (xcu) > Page: 3281 Line: 41011 Section: yacc > Problem: > (yacc: yylex() return type) > Saying that "the values returned by actions and the lexical analyzer > shall > be integers doesn't clearly specify the return type of yylex(). (It > could > be signed or unsigned char, short, int, long, or long long.) > Action: > Change "shall be integer" on P3281, L41011 to "shall be of type int". > (xcu) > Page: 3283 Line: 41085 Section: yacc > Problem: > (yacc: semantic action) > This text is explaining that actions can occur anywhere in a grammer > rule, > but the text used makes it sound like the action cannot occur at the > beginning of a rule. > Action: > Change "in the middle of a rule as well as at the end" on P3283, L41085 > to > "anywhere in a rule (not just at the end)". > (xrat) > Page: 56 Line: 2077-2079 Section: A.9.3.5 > Problem: > Example is missing some text (or diacritical marks). Reproducing (as best > I > can using ASCII) the relevant text on these lines, it says: > > defines 'a as a variant of 'a', while another defines it as a letter > following 'z', then the expression "[a-z]" > > 1) There is a missing close single quote after the first a. > 2) the letters 'a' are not distinguished from each other by diacritical > marks. > Action: > Add quote and distinguish the letters a, for instance, as follows (I will > use the pair "`a" to indicate an a with some form of diacritical mark). > > defines '`a' as a variant of 'a', while another defines it as a letter > following 'z', then the expression "[`a-z]" > > (xrat) > Page: 3311 Line: 25 Section: A.1.1 > Problem: > Add a comment... > Action: > New members of the Legacy group have been added reflecting the advance > in understanding of what is required. > (xrat) > Page: 3314 Line: 162 Section: A.1.4 > Problem: > Add additional clarifier. > Action: > Add at end of paragraph: > In particular, implementation-defined is used where it is believed that > certain classes of application will need to know such details to > determine > if the application can be successfully ported to the implementation. > Such applications are not always strictly portable, but nevertheless are > common and useful; often the requirements met by the application cannot > be met without dealing with the issues implied by > "implementation-defined". > (xrat) > Page: 3315 Line: 194 Section: A.1.5.1 > Problem: > I beieve we got rid of PI in the main body (I sure hope it stays away). > Action: > Delete. > (xrat) > Page: 3326 Line: 561 Section: A.3 > Problem: > "is most common" is no longer true. Posix (OK, ksh) seems to dominate > now. > Action: > ->"was most common when the standard was originally developed". > (xrat) > Page: 3337 Line: 1060 Section: Defitions > Problem: > Minor inconsistency between the description of ls > in XCU and XRAT. In XRAT it says, > "In IEEE Std. 1003.1-200x, the ls utility never follows > symbolic links unless one of the -H or -L options is specified." > while in XCU it is specified that ls does that: > ---------------------- > $ mkdir d > $ touch d/f > $ ln -s d l > $ ls l > f > ---------------------- > Action: > Change line 1063 p 3337 > "In IEEE Std. 1003.1-200x, the ls utility never follows > symbolic links unless one of the -H or -L options is specified." > to > In IEEE Std. 1003.1-200x, unless one of the -H or -L options is > specified, the ls utility only follows symbolic links to directories > that are given as operands. > (xrat) > Page: 3338 Line: 1123 Section: A.3 > Problem: > I believe it has now been determined that the result of raise > and kill-self are considered synchronous. > Action: > Per that resolution, add: Any signal sent via the raise() call > or a kill() call targeting the current process is also considered > synchronous. > (xrat) > Page: 3339 Line: 1127 Section: A.3 > Problem: > This reference points to nowhere, as far as I can find. However, > it should refer to a very important discussion. (Although generally > better understood now than then, many still confuse the two.) > Action: > Add this text to the common preface for Issue 6 (it may need minor > editorial fixes ): > Background > The developers of IEEE Std. 1003.1-200x represent a cross- > section of hardware manufacturers, vendors of operating > systems and other software development tools, software > designers, consultants, academics, authors, applications > programmers, and others. > Conceptually, IEEE Std. 1003.1-200x describes a set of > fundamental services needed for the efficient construction > of application programs. Access to these services has been > provided by defining an interface, using the C programming > language, a command interpreter and common utility programs > that establish standard semantics and syntax. Since this > interface enables application writers to write portable > applications--it was developed with that goal in mind--it > has been designated POSIX,(footnote 1) an acronym for Portable > Operating System Interface. > Although originated to refer to the original IEEE Std > 1003.1-1988, the name POSIX more correctly refers to a > family of related standards: IEEE 1003.n and the parts of > International Standard ISO/IEC 9945. In earlier editions of > the IEEE standard, the term POSIX was used as a synonym for > IEEE Std 1003.1-1988. A preferred term, POSIX.1, emerged. > This maintained the advantages of readability of the symbol > ``POSIX'' without being ambiguous with the POSIX family of > standards. > Audience > The intended audience for ISO/IEC 9945 is all persons > concerned with an industry-wide standard operating system > based on the UNIX system. This includes at least four > groups of people: > __________ > 1. The name POSIX was suggested by Richard Stallman. It is > expected to be pronounced pahz-icks, as in positive, not > poh-six, or other variations. The pronunciation has > been published in an attempt to promulgate a > standardized way of referring to a standard operating > system interface. > __________ > > 1. Persons buying hardware and software systems; > 2. Persons managing companies that are deciding on future > corporate computing directions; > 3. Persons implementing operating systems, and especially > 4. Persons developing applications where portability is > an objective. > Purpose > Several principles guided the development of this : > Application Oriented > The basic goal was to promote portability of > application programs across UNIX system > environments by developing a clear, consistent, and > unambiguous standard for the interface > specification of a portable operating system based > on the UNIX system documentation. > IEEE Std. 1003.1-200x codifies the common, existing > definition of the UNIX system. There was no > attempt to define a new system interface. > Interface, Not Implementation > IEEE Std. 1003.1-200x defines an interface, not an > implementation. No distinction is made between > library functions and system calls: both are > referred to as functions. No details of the > implementation of any function are given (although > historical practice is sometimes indicated in the > RATIONALE. Symbolic names are given for constants > (such as signals and error numbers) rather than > numbers. > Source, Not Object, Portability > IEEE Std. 1003.1-200x has been written so that a > program written and translated for execution on one > conforming implementation may also be translated > for execution on another conforming implementation. > IEEE Std. 1003.1-200x does not guarantee that > executable (object or binary) code will execute > under a different conforming implementation than > that for which it was translated, even if the > underlying hardware is identical. > The C Language > The system interfaces and header definitions are > written in terms of the standard C language as > specified in the ISO C standard. > No Super-User, No System Administration > There was no intention to specify all aspects of an > operating system. System administration facilities > and functions are excluded from > IEEE Std. 1003.1-200x, and functions usable only by > the super-user have not been included. Still, an > implementation of the standard interface may also > implement features not in this > IEEE Std. 1003.1-200x. IEEE Std. 1003.1-200x is > also not concerned with hardware constraints or > system maintenance. > Minimal Interface, Minimally Defined > In keeping with the historical design principles of > the UNIX system, IEEE Std. 1003.1-200x is as > minimal as possible. For example, it usually > specifies only one set of functions to implement a > capability. Exceptions were made in some cases > where long tradition and many existing applications > included certain functions, such as creat(). > Broadly Implementable > The developers of IEEE Std. 1003.1-200x endeavored > to make all specified functions implementable > across a wide range of existing and potential > systems, including: > 1. All of the current major systems that are > ultimately derived from the original UNIX > system code (Version 7 or later) > 2. Compatible systems that are not derived from > the original UNIX system code > 3. Emulations hosted on entirely different > operating systems > 4. Networked systems > 5. Distributed systems > 6. Systems running on a broad range of hardware > No direct references to this goal appear in > IEEE Std. 1003.1-200x but some results of it are > mentioned in the RATIONALE. > Minimal Changes to Historical Implementations > There are no known historical implementations that > will not have to change in some area to conform to > POSIX 1003.1-200x. Nonetheless, there is a set of functions, > types, definitions, and concepts that form an > interface that is common to most historical > implementations. IEEE Std. 1003.1-200x specifies > that common interface and extends it in areas where > there has historically been no consensus, > preferably > 1. By standardizing an interface like one in an > historical implementation; e.g., directories, > or; > 2. By specifying an interface that is readily > implementable in terms of, and backwards > compatible with, historical implementations, > such as the extended tar format defined in > the pax utility or; > 3. By specifying an interface that, when added > to an historical implementation, will not > conflict with it, for example, the function. > Required changes to historical implementations have > been kept to a minimum, but they do exist. > IEEE Std. 1003.1-200x is specifically not a > codification of a particular vendor's product. > It should be noted that implementations will have > different kinds of extensions. Some will reflect > ``historical usage'' and will be preserved for > execution of pre-existing applications. These > functions should be considered ``obsolescent'' and > the standard functions used for new applications. > Some extensions will represent functions beyond the > scope of IEEE Std. 1003.1-200x. These need to be > used with careful management to be able to adapt to > future IEEE Std. 1003.1-200x extensions and/or port > to implementations that provide these services in a > different manner. > Minimal Changes to Existing Application Code > A goal of IEEE Std. 1003.1-200x was to minimize > additional work for the developers of applications. > However, because every known historical > implementation will have to change at least > slightly to conform, some applications will have to > change. > (xrat) > Page: 3358 Line: 1862 Section: A.7.3.5 > Problem: > The example dates given on this and the following line are shown in the > U.S. specific form (m/d/y). This may be confusing for e.g. European > readers. > Action: > Change "7/4/1776" to "July 4th 1776" > Change "7/14/1789" to "July 14th 1789" > (xrat) > Page: 3360 Line: 1926 Section: A.8.3 > Problem: > I can't make "6" characters out of this anyway I can imagine. > Action: > 6->5 > (xrat) > Page: 3369 Line: 2262 Section: A.11 > Problem: > Times change. > Action: > "uses" -> "used". > (xrat) > Page: 3375 Line: 2505 Section: A.12.1 > Problem: > The statement that the command on line 2504 would be a syntax error > seems too strong. Section 12.2 in the Base Definitions says (line 7465) > that ranges greater than the signed 31-bit values are allowed, so an > implementation could syntactically accept the option value 3000000000, > yet reject it on semantic grounds. > Action: > Change "would be a syntax error" to "could be a syntax error". > (xrat) > Page: 3384 Line: 2731 Section: B.2.2 > Problem: > "furthers the goal". Mostly this goal has been reached. > Action: > Delete sentence (altho if someone wants to recast it to reflect > future amendments, that's fine with me.) > (xrat) > Page: 3391 Line: 3015 Section: B.2.3 > Problem: > wrong word. > Action: > "block" -> "blocking". > (xrat) > Page: 3401 Line: 3486 Section: omitted > Problem: > A bit salesy, here. > Action: > replace paragraph with: > The application writer is presented with a choice; the System V > interfaces or the POSIX interfaces (loosely derived from the Berkely > interfaces). The XSI profile prefers the System V interfaces, but > the POSIX interfaces may be more suitable for realtime or other > performance sensitive applications. > (xrat) > Page: 3405 Line: 3661 Section: B.2.8 > Problem: > The description of Ada rendez-vous is out of date. The current Ada > standard includes priority queuing. > Action: > Delete the sentence containing the word "Ada". > (xrat) > Page: 3418 Line: 4257 Section: B.2.8.3 > Problem: > Fortran is described as a language without pointers; I believe this is > out of date with the current Fortran standard. > Action: > Change "However, in languages such as FORTRAN, it will not work > because these languages do not have pointer types." > to > "However, in languages without pointer types it will not work." > (xrat) > Page: 3419 Line: 4295 Section: B.2.8.3 > Problem: > Commands are in-scope . > Action: > Delete the paragraph at 4295-4297 > (xrat) > Page: 3419 Line: 4311 Section: B.2.8.3 > Problem: > A lower-level standard (ANSI Ada) is referred to, where a higher-level > standard exists (ISO Ada). > Action: > Change "ANSI Ada" to "ISO Ada". > (xrat) > Page: 3460 Line: 6151 Section: B.2.9 > Problem: > 1) "POSIX.1" is a bad reference. > 2) *If* I understand what this is referring to, it's no longer true. > Action: > Delete paragraph. > (xrat) > Page: 3516 Line: 8443 Section: C.1.9 > Problem: > POSIX.1a is "us". > Action: > "value in..." -> "value for the system interfaces". > (xrat) > Page: 3550 Line: 9768 Section: C.3 > Problem: > What annex; what output displays? > Action: > Delete paragraph. > (xrat) > Page: 3550 Line: 9800 Section: C.3.1 > Problem: > Dangling ")". > Action: > Delete. > ___________ end of summary _____________ > > Lisa Rajchel > ANSI > 11 West 42nd Street > New York, NY 10036 > Telephone: (212) 642-4932 > Fax: (212) 840-2298 > Email: lrajchel@ansi.org <> > >