Austin/71
Minutes of the 6th Plenary Meeting of the Austin Group
5-9 Mar 2001
Alameda, Oakland, California.
Hosted by Lucent.
Attendees
| Name | Affiliation | Role |
| Andrew Josey | The Open Group | Chair |
| Nick Stoughton | Usenix | WG15, Secretary |
| Don Cragun | Sun Microsystem | IEEE |
| Mark Brown | IBM | The Open Group |
| Andrew Gollan | Sun Microsystems | |
| Joanna Farley | Sun Microsystems | |
| Frank Prindle | DoD/DISA | |
| Donn Terry | Microsoft | |
| Ulrich Drepper | Red Hat | |
| Keld Simonsen | DKUUG | |
| Finnbar Murphy | Compaq | |
| Jim Meyering | Lucent | Host |
| Peter Van Der Veen | QNX | |
| Cathy Hughes | The Open Group | Editor |
Andrew Josey called the sixth meeting (a.k.a. Austin/M7, since this counting includes a teleconference) of the Austin Group to order at 9:20 am Monday March 5th at the Oakland facility of Lucent Technology.
Meeting Goals
The goal of this meeting is to review the draft five Common Specifications. The bulk of the meeting will be spent doing issue resolution based on Aardvark comments submitted during the review period. Many of the comments have been predisposed by the editors. These will not be discussed unless there is some disagreement with the proposal.
added items for "atexit()", "lio_listio()", "kill utility", and "ftw and large files". We will discuss byte v character and non power of two / multiple of 8 bit bytes when the relevant aardvarks are visited.
Minutes were published as Austin/57. No comments received. Minutes approved.
Following AIs were addressed in the meeting, not having been closed beforehand:
2000-10-10 ... Andrew Gollan reported this is covered by aardvark submitted on D5
2000-10-12 ... Andrew Gollan reported this is still open; it may well be covered by some aardvark this week.
2000-10-28 ... Donn Terry reported that Keith Bostic agrees that his implementation is non-conforming, and the text as in 1003.2b is as it should be. The "." command does not redo a "u" undo.
2000-10-48 ... Andrew Gollan reported this is closed by an aardvark submitted against d5
2000-10-51 ... Andrew Gollan reported this is closed.
SD1 updated
SD2 updated
No updates ... Andrew Josey gave a brief explanation for anyone new.
see attendance list above.
In IEEE ballot, we have achieved 82% affirmative.
In ISO ballot, we have one negative and two other comments to dispose.
There are two further drafts expected, D6 and D7. D6 in April, D7 in June. This will be revisited later in the week.
@ page 822 line 11493-11496 section feclearexcept objection [CDWF-524]
Problem:
Though the return type of various functions have been changed in
accordance with C99 DR202 (part of TC1), their functionality hasn't.
Action:
On line 11493, change "clears" to "attempts to clear". Replace line
11496 with:
If the argument is zero or if all the specified exceptions were
successfully cleared, feclearexcept() shall return zero. Otherwise
it shall return a non-zero value.
On page 823, line 11522, change "store" to "attempt to store". On line
11524, change "establish" to "attempt to establish". Replace line 11530
with:
If the representation was successfully stored, fegetenv() shall
return zero. Otherwise it shall return a non-zero value.
If the environment was successfully established, fesetenv() shall
return zero. Otherwise it shall return a non-zero value.
On page 824, line 11555, change "store" to "attempt to store". On line
11558, change "set" to "attempt to set". Replace line 11564 with:
If the representation was successfully stored, fegetexceptflag()
shall return zero. Otherwise it shall return a non-zero value.
If the excepts argument is zero or if all the specified exceptions
were successfully set, fesetexceptflag() shall return zero.
Otherwise it shall return a non-zero value.
On page 825, change lines 11598-11600 to:
The fesetround() function shall return a zero value if and only if
the requested rounding direction was established.
On page 829, line 11698, change "raise" to "attempt to raise". Replace
line 11704 with:
If the argument is zero or if all the specified exceptions were
successfully raised, feraiseexcept() shall return zero. Otherwise it
shall return a non-zero value.
On page 836, lines 11824-11826, change "save" to "attempt to save",
"install" to "attempt to install", and "raise" to "attempt to raise".
Replace line 11829 with:
The feupdateenv() function shall return a zero value if and only if
all the required actions were successfully carried out.
@ page 886 line 13535 section fprintf objection [CDWF-525]
Problem:
Wording needs changing to come into alignment with C99 DR210 (part of
TC1).
Action:
On line 13535, change "If FLT_RADIX is not a power of 2" to "For a and A
conversions, if FLT_RADIX is not a power of 2 and the result is not
exactly representable in the given precision".
Make the same change on page 949 line 15711.
On page 1958 line 44879, change "and FLT_RADIX is not a power of 2" to
"FLT_RADIX is not a power of 2, and the result is not exactly
representable".
Make the same change on page 2131 line 49940.
@ page 1235 line 24436 section mbrtowc objection [CDWF-526]
Problem:
Wording needs changing to come into alignment with C99 DR213 (part of
TC1).
Action:
Change "positive" to "between 1 and n inclusive".
@ page 1193 line 23187-23196 section localeconv objection [CDWF-527]
Problem:
Wording needs changing to come into alignment with C99 DR234 (part of
TC1).
Action:
Change "int_currency_symbol" to "int_curr_symbol" (in four places).
After line 23216 add a paragraph:
For int_p_sep_by_space and int_n_sep_by_space, the fourth character
of int_curr_symbol is used instead of a space.
This is a contentious issue coming from OGTGBase. While it is generally felt that namespace reservation may not be totally inappropriate, the use of this for extended attributes for files has caused much heated discussion. Ulrich suggested that if the only problem to solve is extended attributes, then the better way to deal with this is to add a whole new set of attribute getting and setting interfaces. Donn Terry stated there were 3 distinct problems:
Putting this into the draft will reduce consensus. We will not progress this any further in this group.
Andrew Josey pointed out that some of the complex math functions should probably move to a different sub-profile. Frank Prindle has submitted aardvark for a number of other sub-profile changes. There are several sub-options that are hard to split out (particularly wide-character), because they are in many headers. All attendees should read the sub-profile chapter (XBD Chapter 2) before addressing the aardvark. Conceptually, are the options the ones we want -- do any need adding/deleting etc.
Much discussion on whether or not sub-profile options should be in the document at all. We did agree in an earlier meeting that this should be addressed. However, it may be making problems for the future (especially for future profiles) if we do this here, and wrongly. We have reasonable consensus on the options as expressed in D5. Some vendors (e.g. QNX) currently offer slice and dice, but with different sub-profiles. Options are remove it, leave it (but its wrong), or fix it (but how do you know you've fixed it?) We cannot predict the future ... what profiles will require what functions. Which group should a particular function be in?
Suggestion: document the rules that permit other standards to sub-profile, but with the
additional rule that any application that conforms to a sub-profile must also conform to
the base standard. Also, the base standard itself satisfies all the constraints of any
sub-profile. Move the current sub-profiles chapter (as amended by aardvark) to an
informative annex. Add rationale explaining the problem and why we didn't make these
option groups normative.
ACTION IEEE OR to forward revised sub-profiling proposal to the PASC/SEC for their approval.
Revisited.
Frank Prindle has reworked the functions list into a separate chapter, which should become
an informative annex.
The conformance chapter also needs work to lose any symbols added for subprofiling, and
someone needs to write the subprofiling section.
ACTION Frank Prindle to provide new normative text for Subprofiling options.
ACTION Andrew Josey to rework chapter 2, provide the new annex and unistd.h and recirculate.
Secretary's Note: In various places in the following aardvark dispositions, where the secretary was particpating in the discussion, the actual resolution was captured by the editor, and not here. Please review the aardvark comments circulated by the editor for full details of the final decision. For the avoidance of doubt the aardvark reports are the master documents.
Remove from pre-disposed list: 148, 161, 199, 223, 224, and 372.
This list shows only the ERNs discussed at the meeting. Others were pre-disposed.
XBD ERN 2: Accept
XBD ERN 4: Reject. The interp (#60) did not bring this into scope, since it was not tagged as a defect or referred to sponsor. The currently approved standard (1996) does not make any requirement in this area either. It is not in our scope to invent new rules here. The interpretation made it clear that this was not a requirement. Additionally, there is no requirement in FIPS-151. Although the group agreed that in principle this was not an unreasonable request, we were unable to find any opening in our scope to permit any change.
XBD ERN 5: addressed elsewhere (CRB style ERN)
XBD ERN 6: Dup 2.
XBD ERN 8: Dup 5.
XBD ERN 11: AAM - change bars are made automatically. The editors will attemt to avoid this by making hte standard name change first, then using this as the baseline for further diffmarking.
XBD ERN 12: Accept; keep 796-803, make other changes as specified.
XBD ERN 14: Accept
XBD ERN 15: Accept (add note as described). ACTION: TOG OR to refer this to the Base WG. CLOSED
Revisited --- the Base Working group decided to approve a resolution removing the UN shading throughout. (get rid of this section and remove markings for uucp, uustat and uux utilities).
XBD ERN 58: Reject; although sometimes difficult to understand, the concept of maximum minima and minimum maxima took a long time to be developed, and still seem to be the best way to express the concept.
XBD ERN 59: Reject; although sometimes difficult to understand, the concept of maximum minima and minimum maxima took a long time to be developed, and still seem to be the best way to express the concept.
XBD ERN 61: Accept - delete the sentence
XBD ERN 62: AAM - change "Person" -> "User"
XBD ERN 63: Accept - remove the sentence
XBD ERN 64: Accept
XBD ERN 65: Accept
XBD ERN 66: AAM - change "Person" to "User"
XBD ERN 67: AAM - delete first para of note. Delete "Such" from second para. Change 3rd para to forward ref to XCU 3.1.2.
XBD ERN 68: Accept
XBD ERN 69: AAM - use as suggested with spelling corrections.
XBD ERN 70: AAM - also include the abnormal termination wording dropped. Andrew has words.
XBD ERN 71: Accept
XBD ERN 72: AAM - change "Person" to "User"
XBD ERN 73: AAM - use first alternative.
XBD ERN 74: OK, we hit the byte v character 8-bit discussion! OR vote was called for (Donn Terry). The vote is on accepting 76. TOG - yes. IEEE - yes. ISO - yes. Unanimous. AGREED - Bytes are 8-bits, other implementations are no longer POSIX conforming. We recognize that C99 puts us in a hard spot; we have the choice of accepting C99, having 8 bit bytes and networking; or throwing out either C99 or networking. Neither throwing out C99 or throwing out networking is acceptable. The compromise is. 74 is DUP 76
XBD ERN 75: Reject - see 76.
XBD ERN 76: Accept (as marked ... remove the last sentence of the note)
ACTION - Andrew Josey to supply rationale for 8-bit bytes (culled from the email discussion).
revisited Friday. Donn Terry has noticed a potential problem here ... what about
interfaces such as getpid() or getuid() which return a pid_t/uid_t is returned ... if the
uid would not fit into the now restricted type, then the function should fail and set
errno to EOVERFLOW. But what should the function return? -1 might be a valid uid for
example. How about a reserved symbolic failure value? Or we could use the errno finesse.
Nobody likes the errno finesse! A currently conforming app that calls getpid() (which is
defined today as having no possible failures) could now start receiving errors. The
application would have to rewrite the code, thus defeating the entire purpose of the
special restricted environment.
ACTION Donn Terry to provide words using a distinguished fail value for use in restricted environments.
This is going to come back and bite us again.
XBD ERN 80: Accept
XBD ERN 98: Reject. Although technically accurate, the term "pseudo-seconds" adds no further clarity or crispness to the definition. The orignal has been in common usage since at least the pseudo-epoch. It is believed that change suggested would considerably reduce consensus.
XBD ERN 121: Defer to Fred Tydeman. Revisited, AAM, agreed wording is inconsistent, Andrew will fix.
XBD ERN 133: Accept
XBD ERN 136: AAM - use the first suggested alternative.
XBD ERN 137: Reject - This is a requirement from previous POSIX versions. Applications depend on this. It is also explicitly defined this same way in ISO 9899: 1999, section 5.2.1 para 2.
XBD ERN 138: Reject - although this section overlaps with functionality specified in c99, it is derived from earlier POSIX standards, and is not intended to be an extension of the c99 extended character set.
XBD ERN 139: Reject - we cannot find any contradiction between the sections quoted. There is some redundant text, but this helps the readability. Leave it alone!
XBD ERN 148: Reject - this would be a difference over the base docs; the tables do differ (albeit by having aliases for some of the charactyers, IS1-IS4)
XBD ERN 152: AAM - remove the second "escape" from 4043.
XBD ERN 161: Reject - the normative effect of either the current phrase or the replacement is the same; the current phrase is acceptable English language, and is easier to understand.
XBD ERN 162: Accept
XBD ERN 163: probably AAM - delete line 4111. Also note that sentence starting on line 4093 "Implementations supporting other byte sizes may allow constants to represent values larger than those that can be represented in 8-bit bytes, and to allow additional digits in constants." should be deleted. ACTION Donn Terry to write text describing "increasing order" in a character set description file. (see XBD ERN 163) Still open.
XBD ERN 165: Dup 139, Reject.
XBD ERN 166: Dup 139, reject
XBD ERN 192: AAM - remove the entire sentence "In contexts where standards (such as the ISO C standard) limit the mon_decimal_point to a single byte, the result of specifying a multi-byte operand is unspecified.". Similarly for mon_thousands_sep.
XBD ERN 194: dup 192
XBD ERN 195: Accept
XBD ERN 196: There is historic practice in both directions ... recent implementations of glibc have corrected the bug quoted. Reject.
XBD ERN 199: Open ...
ACTION Yvette Ho Sang to give direction for AD v CE.
Revisited. We have had an inital response; if there is no follow-up, we will leave
this alone.
XBD ERN 200: withdrawn by objector.
XBD ERN 204: Accept
XBD ERN 205: Accept
XBD ERN 216: (Accept) defer Collation subgroup
XBD ERN 217: (Accept) defer Collation subgroup
XBD ERN 218: (Accept) defer Collation subgroup
XBD ERN 219: (Accept) defer Collation subgroup
XBD ERN 221: defer Collation subgroup
XBD ERN 223: AAM - use ed recommendation
XBD ERN 224: AAM - use ed recommendation
XBD ERN 227: no clear change proposed. The group felt that a number of the lower speeds
(e.g. B50-B600) and small values for CSIZE (e.g. CS5 and CS6) might well be obsolescent.
There are many higher speeds used by modern systems. If no explicit change is submitted
this week, we will take the path of least resistance (i.e. no change).
Another proposal is to AAM; copy sentence from previous table. Delete second sentence
starting on 7195, and replace with "The symbols in the following table shall be defined in
XBD ERN 237: Accept
XBD ERN 290: Accept
XBD ERN 291: Reject - withdrawn by objector
XBD ERN 292: Reject - withdrawn by objector
XBD ERN 293: Reject - withdrawn by objector
XBD ERN 295: Accept
XBD ERN 296: Accept
XBD ERN 297: Reject - editorial, editors do not believe it is required.
XBD ERN 298: Reject - this is terminology from the base standard, and indeterminate is
the correct phrase here.
XBD ERN 300: Accept
XBD ERN 301: Accept
XBD ERN 302: Accept
XBD ERN 303: AAM - use TASA not must. Also need to change XSH p 904 lines 14161/2
correspondingly.
XBD ERN 304: Accept
XBD ERN 305: Reject - see XBD ERN 76 and Austin_SD2 Consent list item 32.
XBD ERN 306: Accept
XBD ERN 307: Accept
XBD ERN 308: defer -
ACTION TOG OR to refer this to OGTGBase for their consideration Wednesday evening.
XBD ERN 309: Reject - see XBD ERN 76 and Austin_SD2 Consent list item 32.
XBD ERN 310: Accept - see XBD ERN 76 and Austin_SD2 Consent list item 32.
XBD ERN 311: Accept
XBD ERN 312: This is a legitimate request, in scope. The interp against .2 is
different, since that standard used 'arithmetic types', this revision uses 'signed integer
types'. This is a consitency issue caused by alignment with c99. Accept.
XBD ERN 313: Reject, out of scope.
XBD ERN 314: Accept
XBD ERN 315: Accept
XBD ERN 317: Reject, the term used is correct. NOTE change must to shall to align
correctly with the C standard.
XBD ERN 318: OK ... another big discussion block! See 322
XBD ERN 319: See 322
XBD ERN 320: See 322
XBD ERN 321: See 322
XBD ERN 322: Mark Brown made a proposal that there should be a programming environment
where size_t is no bigger than a long. Don Cragun made the point that
XCU c99 table 4-4 (page 2428) provides a starting point for this ... we
should add a requirement that at least one of _POSIX_V6_ILP32_OFF32 or
_POSIX_V6_LP64_OFF64 be supported. Andrew Gollan suggested that this
alone might be restrictive (e.g. for 128 bit systems). A better
suggestion is to add a row to this table _POSIX_V6_PTR_FITS_LONG (or
whatever), where bits in int >= 32, bits in long >= 32, bits in ptr =
bits in long, bits in off_t = bits in long. This addresses the problems raised in all
these negative ballots, while not restricting the implementation to using forward looking
features from c99. There should also be a warning that a future revision of the standard
might remove the restriction that this environment must be supported (to encourage
application developers to write new code that is portable within c99 constraints). This is
now an AAM.
The name is actually not an extra row, but a getconf name that must be
supported that returns the name of a compilation environment from table 4-4 where pointer
fits in a long.
None of the changes proposed in this aardvark need be made if there is a guarantee that
the named types will always fit in a long.
Here is the markup:
XBD ERN 323: See 322
XBD ERN 324: See 76. AAM, add rationale explaining that as a consequence of requiring
int8_t means that:
XBD ERN 325: Accept
XBD ERN 326: Accept
XBD ERN 327: Withdrawn by objector
XBD ERN 328: Accept
XBD ERN 330: Accept
XBD ERN 332: Reject - out of scope. This text is from exisating standards, and no
interp has been filed.
XBD ERN 333: Accept
XBD ERN 334: AAM - take ed recommendation
XBD ERN 335: Accept
XBD ERN 337: Defer to OGTGBase.
ACTION TOG OR to convey this to the Wednesday meeting.
XBD ERN 338: Withdrawn by objector
XBD ERN 339: Reject - select does modify the timeval struct.
XBD ERN 343: Accept (we believe the term is well understood without a definition)
XBD ERN 345: Reject - out of scope.
XBD ERN 348: dup 349
XBD ERN 349: Accept
XBD ERN 350: Accept
XBD ERN 351: AAM - change 13088-13090 to refer to sys/select.h as well.
XBD ERN 352: Accept
XBD ERN 355: Accept (dup 353)
XBD ERN 356: dup of 4
XBD ERN 357: Accept
XBD ERN 358: Accept
XBD ERN 359: Accept
XBD ERN 363: AAM - reword the para slightly. Editors have words
XBD ERN 364: AAM - part of same rewording above.
XBD ERN 365: Accept
XBD ERN 366: Reject - out of scope, carried forward from base document (and yes,
multiple versions can be supported simultaneously, even with cuserid()!)
XBD ERN 367: Reject. The rationale on page 430 explains how these constants should be
used. This is a requirement from 1003.1a, where it took many years to reach consensus!
Implementations do not want to have to release a new revision of their system to say they
do not support a new (or third party) option.
XBD ERN 368: Accept
XBD ERN 369: AAM, and on 14290. And allow fpathconf() too.
XBD ERN 370: Accept
XBD ERN 371: Accept. Question on value of version: is there one final vote or three? If
three, which one is used for version strings?
ACTION ALL ORs to refer this to their representative on the JPROC committee (note resolution is required by April 10)
XBD ERN 372: Reject - see ed recommendation
XBD ERN 377: AAM - Replace 14468-14469 with:
This symbolic constant shall be defined to be the value of a character that shall
disable special character handling as described in termios.h
XBD ERN 378: Defer to OGTGBase.
XBD ERN 379: Withdrawn by objector
XBD ERN 380: Editorial ... leave this to the editors (Accept)
XBD ERN 381: Accept
XBD ERN 384: AAM (Andrew has words, or will have!)
XBD ERN 390: This is actually an XSH aardvark ... defer to XSH discussion.
XBD ERN 391: This is actually an XSH aardvark ... defer to XSH discussion.
XBD ERN 393: This is actually an XSH aardvark ... defer to XSH discussion.
Donn Terry asked for 163 and 469 to be removed from the pre-disposed list.
XCU ERN 001: Accept
XCU ERN 002: Defer to IEEE Editor.
ACTION IEEE Editor (Yvette) to provide acknowlegements. CLOSED
XCU ERN 009: Defer -- revisit tomorrow.
[Tomorrow has arrived ...]
We reworked some of the items in the table proposed by Donn. This is almost correct, but
Andrew still is unclear on what is needed - defer again.
ACTION Donn Terry to finish the proposal for XCU ERN 2 completely and resubmit. CLOSED
XCU ERN 024: Defer -- revisit tomorrow.
[Tomorrow has arrived ...]
Change the first sentence as stated.
Reword sentence 2 (Editor has words)
XCU ERN 027: AAM (Andrew has words)
XCU ERN 061: Accept
XCU ERN 064: Accept
XCU ERN 065: Accept
XCU ERN 066: AAM (resp == respectively)
XCU ERN 072: Accept
XCU ERN 073: AAM, change "passed along" to ", passed to the new shell"
XCU ERN 074: AAM. Split sentence into two, period after "command execution". Second
sentence starts "In this case" and uses shalls.
XCU ERN 075: AAM - same as similar case (73).
XCU ERN 078: Accept
XCU ERN 080: AAM - Andrew has words (essentially identical to 1992 text)
XCU ERN 081: withdrawn by objector
XCU ERN 082: Accept
XCU ERN 083: Accept
XCU ERN 084: Accept
XCU ERN 085: Accept
XCU ERN 092: Accept
XCU ERN 104: AAM - "does not always" -> "need not"
XCU ERN 105: Accept
XCU ERN 106: Withdrawn by objector
XCU ERN 108: Accept
XCU ERN 110: Accept
XCU ERN 111: Accept
XCU ERN 112: Accept
XCU ERN 113: Accept
XCU ERN 114: AAM - editor has words
XCU ERN 115: AAM - similar change to 114
XCU ERN 117: Accept
XCU ERN 118: Reject - this change actually alters the meaning in this case. This is
just English, not the formal use of must to imply a requirment on the application.
XCU ERN 120: Defer to tomorrow [tomorrow has arrived]: Donn Terry proposed moving the
text describing batch administrator and batch operator from page 2316 to the equivalent
spots in XBD, replacing the rather handwavy ones there. Having moved them, add a xref to
these defns here. AAM
XCU ERN 121: Accept
XCU ERN 122: Reject - fixed by 121
XCU ERN 123: Reject - fixed by 121
XCU ERN 127: Reject -- this appears to be observation of fact, no change required
XCU ERN 129: AAM - change line 3876 to change "is" to "shall always be" and
"several" to "the following". However, leave "should" and leave the note.
XCU ERN 130: Reject - the group believe that this is defined more completely in the q*
utilities, and believe that making a change here could lead to unintended conflicts.
XCU ERN 132: Accept
XCU ERN 134: AAM (Andrew has words)
XCU ERN 135: Accept
XCU ERN 150: dup 152
XCU ERN 151: dup 152
XCU ERN 152: Accept
XCU ERN 162: Accept (after a fair amount of discussion and experimentation!)
XCU ERN 163: AAM - take ed recommend
XCU ERN 166: Accept
XCU ERN 179: Defer to IEEE Editor.
XCU ERN 182: withdrawn by objector
XCU ERN 185: Accept
XCU ERN 188: Accept
XCU ERN 196: AAM; take ed recommendation, split into two.
XCU ERN 208: Accept
XCU ERN 209: AAM - change "extensions" to "options".
ACTION Andrew Josey to check fcntl.h for any ADV RT dunctions.
XCU ERN 210: Accept - we note the problem statement should read "Trace Functions" not
"Advanced Realtime" ... take action as suggested.
XCU ERN 211: Defer to IEEE.
XCU ERN 216: dup 217
XCU ERN 217: AAM, change from 8841 "Files ..." to end of para.
XCU ERN 219: Accept
XCU ERN 220: Accept
XCU ERN 221: Accept
XCU ERN 222: Accept
XCU ERN 224: AAM - the next two paragraphs should be indented under the :
XCU ERN 225: The basic rule everywhere in the doc is that pathnames are resolved using
the rules of pathname resolution, unless there is a specific mention of symlinks. The
document is clear, we do not believe that this change is required. An interpretation
request would be needed to change this. Reject
XCU ERN 226: Reject. Copying ACLs is allowed elsewhere (see General Concepts 4.3). This
is intended to copy bits. Replacing "Other" with "Additional" is not necessary. Removing
the commas adds ambiguity.
XCU ERN 243: Reject - no change required. This is what was intended.
XCU ERN 245: Defer to Base WG tonight:
XCU ERN 246: Accept
XCU ERN 247: Defer to Base WG
XCU ERN 248: Defer to Base WG
XCU ERN 250: AAM ... much discussion on Symlinks and other file types ... change the
second sentence of this para to make all other file types implementation defined.
XCU ERN 251: Reject, not needed.
XCU ERN 253: Accept
XCU ERN 254: AAM, used second alternate
XCU ERN 255: Reject, "vertical-line" is the 10646 name
XCU ERN 257: A lot of discussion ... if we add socket for 258, this should cover all
cases. Reject
XCU ERN 258: AAM, add "socket" to the list on 16889 and the table 4-8. All other file
types are covered by the existing words.
XCU ERN 263: Accept
XCU ERN 265: Defer to Base WG SCCSathon
XCU ERN 266: Defer to Base WG SCCSathon
XCU ERN 280: Defer to Base WG SCCSathon
XCU ERN 282: Defer to Base WG SCCSathon
XCU ERN 287: The group understands that automated testing is unreasonable in this
context, but could not agree on how to get the wording better (especially without a global
search and destroy for system reboot). System Reboot is defined in XBD. The pre-first use condition
need not be detectable, or re-enterable. This is also material coming from a base doc with
no interp etc. Reject.
XCU ERN 288: Accept
XCU ERN 289: Accept
XCU ERN 291: This is either TASA or no change ... decided on no no change. Reject.
XCU ERN 300: AAM - Andrew has words. Split first sentence into two, dealing separately
with hard links and symlinks.
XCU ERN 304: Accept (w/mods ... change "secondary key of" to "secondary key being")
XCU ERN 311: Accept
XCU ERN 336: In spite of the fact that the 32-bit 'ness of this is probably a historic
accident, there was a feeling that since this has been standardized since at least XPG2,
it is now too late to change this. On the other hand this over-constrains something that
need not be constrained. Many feel that it could break existing apps that rely on the
maximum size of this being constrained. Reject.
XCU ERN 390: A lot of discussion on TASA versus user ensuring. We don't want to change
the definition of TASA. We believe that TASA implictly works here. Withdrawn by objector.
XCU ERN 398: Accept
XCU ERN 399: dup 1
XCU ERN 401: dup 1
XCU ERN 402: Reject ... additional permission attributes are covered elsewhere (see XBD
4.3 Extended Security Controls).
XCU ERN 404: AAM - shallify, and get the words "option-argument" in. Andrew has words.
XCU ERN 415: AAM - add 8859 3-10 and 13-16. Cathy will get the dates from ISO. Also add
to normative references.
XCU ERN 417: AAM - we all agree on the problem, but how to fix it is harder!
Don Cragun suggests adding at line 27493 "Attempts to archive a socket shall produce a
dignostic message, handling of other file types is implementation defined".
XCU ERN 418: AAM - add symlink to list on 27563. Lots of other discussion around
various other file types, but not really arriving at concensus. Some discussion on the
spacing in the table (416) ... move around entries to preserve the original (believed)
intent of the groupings in this table.
XCU ERN 420: AAM, use the actual numbers, not giga etc.
XCU ERN 421: Withdrawn by objector (the answer to Donn's question is "No").
XCU ERN 424: This would require an interp to alter the text; everyone believed they
understood. The problem statement is vague ... and Donn was not able to convince the group
that there was a real problem. Withdrawn by objector (Note if anyone wants to re-object,
it should be as an interp on the base standard).
XCU ERN 426: Accept.
ACTION Donn Terry to enumerate all places where there is a 2 digit year to add this same note.
XCU ERN 428: Defer to BWG SCCSathon
XCU ERN 435: AAM - delete "bitwise" (the bitwise seems to have snuck in by accident
after a global change)
XCU ERN 438: AAM - "maximum number of jobs that shall be run in ..."
XCU ERN 439: AAM, as 438
XCU ERN 440: AAM, as 438
XCU ERN 441: AAM, as 438
XCU ERN 445: defer to BWG SCCSathon
XCU ERN 453: AAM (use shall not may, change wording around D command) Andrew has words.
XCU ERN 458: This is the way it came from the base doc. Some implementations do have
special escaped chars. Needs an interp. Reject.
ACTION Donn Terry to file an interpretation for XCU ERN 458.
XCU ERN 462: Accept
XCU ERN 469: AAM use ed recommendation
XCU ERN 472: Accept, note also on 33891.
XCU ERN 473: Accept
XCU ERN 474: Accept
XCU ERN 475: Accept
XCU ERN 476: Accept
XCU ERN 477: this table conveys different information; withdrawn by objector
XCU ERN 478: AAM - use all caps. Split into two separate clauses.
XCU ERN 484: Rationale ... withdrawn by objector.
XCU ERN 485: AAM - change midnight to 00:00:00.
XCU ERN 488: Not required. Withdrawn by objector.
XCU ERN 492: This is a non-normative note ... no shall. Should the note move to app
usage? It has been there at least since XPG3. Leave it. WBO.
XCU ERN 497: The ! would cause an ambiguity at the head of a pipeline. AAM, add to the
end of 37207 in "(See the command string operand below)". Leave the cannot observation.
AAM.
XCU ERN 500: Accept
XCU ERN 501: AAM - use "indicated by" rather than adjacent.
XCU ERN 505: Defer to BWG
In the text below, it's the issue of requirement; if the implementation is REQUIRED
to enumerate all its ptys when who -l is used, then I have a problem. If there's
some concept of "doing something" about waiting (running a getty, to put it in
real but non-standard terms) then I don't think the current text quite says that.
"Is actively waiting" might. It would also be reasonable to add rationale to the
effect that the intent is to enumerate the gettys. Otherwise I see an overzealous
test writer trying to get it to enumerate ptys.
There is a lot of difficult issues here. Is a pseudo-tty associated with telnetd, waiting
for someone to login, listed by who -l? No. This is still not meeting the criteria ...
login is defined as an unspecified method for gaining access to the system.
In almost all implementations known, who -l only handles physical lines with getty
running, but there is no easy way to say this.
Adding "actively" does little ... the standard would not be enhanced by this. It is
acceptable for an implementation to produce no output for who -l and conform completely.
Add this to rationale. This changes this ERN to AAM.
XCU ERN 515: Accept
XCU ERN 516: A lot of i18n discussion. Ulrich believes there is no problem. Donn is
sure there is! If the value of a single character cannot be stored in an integer, there
is a problem. Ulrich realizes that there might be a problem if char != byte! One change is
to simply change character to byte or "single-byte character". AAM.
XSH ERN 001: defer -
ACTION Frank Prindle to propose detailed changes to accept XSH ERN 1. CLOSED.
XSH ERN 002: defer -
ACTION Andrew Gollan to propose detailed changes to accept XSH ERN 2.
CLOSED AG provided changes to editor. Ensure that see-also does not refere to a pointer
page.
XSH ERN 005: Actually XBD aardvark ... sounds reasonable ... AAM, also add typed memory
object, appropriately shaded.
XSH ERN 006: This is a tools problem ... tbl overflows with this table! The editors
will attempt to make the breaks between the tables less obvious (by aligning them with
page breaks). AAM. Andrew Josey suggested moving this to the XRAT, as well as the
corresponding change history from XCU.
XSH ERN 007: the original predisposition (reject) was changed by BWG to be a
predisposed Accept before the meeting, and re-predisposed to Accept.
XSH ERN 009: AAM - add rationale as suggested by Ed.
XSH ERN 010: A lot of discussion trying to understand the problem. Should we hold the
developers hand and explicitly unspecify things like this? No. This is covered by p 303
section on "Unspecified". Reject.
XSH ERN 011: although not useful right now, this is a promise of future backwards
compatibility. This originally came from the need to accept rolling amendments, which we
aren't doing any more. Don Cragun wants to accept this, making it only deal with the case
of equal, not >=. AAM. Editors have words.
XSH ERN 013: Dup, see 11.
XSH ERN 014: AAM, use "is enabled", and change "undefined" on 793 to "unspecified".
XSH ERN 015: Accept
XSH ERN 018: Accept
XSH ERN 020: Accept
XSH ERN 023: defer to BWG:
ACTION TOG OR to forward XSH ERN 23 for consideration.
XSH ERN 025: AAM ... all but last action are OK.
ACTION Andrew Gollan to provide specifics for ioctl.
CLOSED - Andrew Gollan proposed words which the group felt adequately covered this; Editor
has words in aardark report.
XSH ERN 026: defer ... mail from Dave Butenhof somewhere on this.
ACTION Finnbarr Murphy to work with Dave Butenhof to provide wording for XSH ERN 26.
XSH ERN 027: This aardvark does not represent a consensus view from the interp process.
Therefore it must be rejected as out of scope until finalized.
ACTION Ted Baker to propose final interp draft for XSH ERN 27 for agreement in IEEE process.
XSH ERN 030: AAM ... move this note to rationale XRAT after 6465.
XSH ERN 031: There may be an interp on this. Reject until interp is finalized.
XSH ERN 032: Defer ...
ACTION Andrew Gollan to provide detailed changes for XSH ERN 32.
Agree with the concept.
XSH ERN 033: Withdrawn by objector.
XSH ERN 034: AAM, Andrew has words.
XSH ERN 035: Accept
XSH ERN 036: Accept
XSH ERN 038: Accept (Shallification required)
XSH ERN 039: Accept (after a lot of discussion....but it is the "right thing to do
[Mark Brown])
XSH ERN 046: Accept
XSH ERN 047: This appears to reverse an earlier dwc aardvark. There is a problem in the
change history. Fix this by deleting 3986-8. AAM.
XSH ERN 055: We think the answer is "no" ... if localization is required you should use
strftime(). WBO.
XSH ERN 060: WBO, it is conforming with another declaration.
XSH ERN 063: WBO, this is the way it is in C99.
XSH ERN 074: Accept as marked, add the text given after 6669. Update the change history
for group -1.
XSH ERN 103: defer to BWG.
ACTION TOG OR to convey XSH ERN 103 to ogtgbase for their consideration.
XSH ERN 106: No change in position. The function is there, its used, out of scope to
alter it or invent new. Reject.
XSH ERN 108: WBO ... should is appropriate, conforming apps must not use should
features.
XSH ERN 113: Accept as marked ... proper alphabetic order.
XSH ERN 117: AAM - make it implementation defined rounding method. IEEE 754 rounds to
even last bit (but 754 is not a normative reference, and is expensive).
XSH ERN 127: AAM - delete "(rather primitive)". Add new para to App usage about the
primitive encoding algorithm used. Shallify first sentence.
XSH ERN 129: Accept
XSH ERN 130: AAM ... Andrew has words
XSH ERN 162: Accept
XSH ERN 173: Accept
XSH ERN 174: AAM, there are two spawn functions.
XSH ERN 175: Accept
XSH ERN 178: AAM - use ed recommendation
XSH ERN 189: defer -
ACTION Andrew Gollan to propose detailed changes for XSH ERN 189.
XSH ERN 194: Accept, Ulrich points out there is variant behavior on fchmod on a socket.
The answer is probably unspecified.
AAM - remove the reviewers note (as resolved). Add the text for STREAM/fattached file. Add
socket as unspecified.
XSH ERN 207: Accept
XSH ERN 209: Reject pending Interp resolution
XSH ERN 212: Accept
XSH ERN 214: Reject - one of these is rationale (though it needs de-shallifying), and
is different from the other.
XSH ERN 215: AAM, ENOLOCK error does not need moving (it is in normative text),
deshallify and remove last sentence. Andrew has detailed markup.
XSH ERN 216: Ther eis a whole body of code that uses lockf, even tho' it is often coded
in terms of fcntl. Reject.
XSH ERN 227: Accept
XSH ERN 234: Accept
XSH ERN 239: Accept
XSH ERN 244: Accept
XSH ERN 258: Accept
XSH ERN 271: Reject. Needs an IR.
The parent remains the controlling process, this is not a property inherited by the child
in a fork. Donn does not think the language says that. There might be a language issue,
but it seems hard to come up with anything better. This is unanmbiguous. No change
required. Donn showing signs of giving in. Withdrawn by objector.
XSH ERN 275: The "Notes" text is not an informative note, but normative description of
what is in the third column of the table. Change the column legend to "Requirements"
AAM
XSH ERN 276: Accept
XSH ERN 277: Accept
XSH ERN 278: Accept
XSH ERN 279: Accept
XSH ERN 280: Accept
XSH ERN 281: Accept
XSH ERN 292: Reject - we could not see the problem (everything is consistent, and in
CW)
XSH ERN 306: dup 117 (at least, they are handled the same way, so maybe AAM)
XSH ERN 313: dup 117 (at least, they are handled the same way, so maybe AAM)
XSH ERN 339: The should is straight from ISO-C. We do not have a strong enough feeling
as to why we should CX this. In C it is clearly flagged as recommended practice. Should
means not mandatory. No change. Reject.
XSH ERN 340: aardvark line numbers appear garbled ... Reject
ACTION Donn Terry to locate and resubmit corrected XSH ERN 340 if appropriate
XSH ERN 341: WBO
XSH ERN 342: WBO
XSH ERN 343: WBO
XSH ERN 344: WBO
XSH ERN 347: Accept
XSH ERN 349: Requirement from base doc. Reject.
XSH ERN 356: Accept
XSH ERN 357: defer
ACTION Andrew Gollan to rework the words to shallify and remove DNS stuff etc. XSH ERN 357
XSH ERN 358: Is this really app usage?
ACTION Andrew Gollan to propose aardvark to move these notes to app usage.
XSH ERN 359: dup of 358
XSH ERN 376: There is a can on the line above, which needs to carry through. Reject.
XSH ERN 377: defer to BWG
ACTION TOG OR to convey XSH ERN 377 to ogtgbase for their consideration
XSH ERN 396: Although ISO C uses 'character' not 'byte', it explicitly only works with
single byte characters. Should we add rationale to explain this?
ACTION Donn Terry to propose words for rationale. Ref XSH ERN 396. CLOSED
Keld wants to extend C to do multibyte,
but others believe that this is not an extension but a complete violation of the C std.
Although we agree with the spirit of this, it just can't be done.
Agreed in principle.
XSH ERN 399: Accept
XSH ERN 416: At best, this is unspecified, not undefined. And they are unspecified by
not saying anything. Reject. We revisited the D4 aardvark, and noted that although we
rejected the previous objection as out of scope, actually we should have rejected this as
no change required, since a directory is a file, and the action of fsync on a directory is
clearly defined by the current text. Reject. File includes directory.
XSH ERN 417: Reject -- this is covered by additional errors. Silence == unspecified.
No change needed. Reject.
XSH ERN 418: Reject. IR needed.
ACTION Donn Terry to file an IR to bring this into scope.
XSH ERN 420: According to the base docs, ftw() is thread safe. Ask BWG for
advice.
ACTION TOG OR to forward XSH ERN 430 to ogtgbase for their consideration.
OPEN
XSH ERN 440: AAM see 117
XSH ERN 446: AAM see 117
XSH ERN 477: WBO - see Clive Feather note
XSH ERN 479: Accept
XSH ERN 480: Changing ISO C requirements ... reject.
XSH ERN 481: Changing ISO C requirements ... reject.
XSH ERN 482: Changing ISO C requirements ... reject.
XSH ERN 483: Changing ISO C requirements ... reject.
XSH ERN 484: Changing ISO C requirements ... reject.
XSH ERN 486: Changing ISO C requirements ... reject.
XSH ERN 514: Accept
XSH ERN 518: Accept
XSH ERN 519: See 523
XSH ERN 522: Quick wrestle with what the heck this was supposed to mean. We think it
means that if the locale spec contains unsupported conversion chars, then %c, %x and %X
won't work. Defer to BWG
ACTION TOG OR to refer XSH ERN 522 to ogtgbase for their consideration.
XSH ERN 523: Accept
XSH ERN 524: Accept
XSH ERN 525: dup 524
XSH ERN 537: Reject
XSH ERN 545: Accept (and note that a corrigenda will be needed in base)
ACTION TOG OR to request corrigenda for XSH ERN 545.
XSH ERN 546: Accept
XSH ERN 547: Accept
XSH ERN 550: most historic docs use size_t, but this was a change in XNS5.2. Finnbarr
believe it is enshrined in Richard Stevens latest edition. Defer to BWG.
ACTION TOG OR to refer XSH ERN 550 to ogtgbase for their consideration
XSH ERN 551: Reject - unnecessary to speculate about something that may be
controversial at IETF.
XSH ERN 553: WBO
XSH ERN 558: WBO
XSH ERN 567: AAM - -> any available message shall be ...
XSH ERN 571: WBO
XSH ERN 572: AAM ... remove "just".
XSH ERN 576: Reject...flags should not be signed. We can see no possible use for a
signed flags arg, and no bad consequences for applications if an implementation assumes
signed.
XSH ERN 578: Accept
XSH ERN 580: The errors section covers this. We could treat cannot as an observation
here. Or remove the sentence. AAM Remove the sentence.
XSH ERN 582: l 17550 add a new error for EAI_FAIL for the node buffer or service
buffer being too small.
Should we use ENOMEM instead of EAI_FAIL?
No closure ....
ACTION Andrew Gollan to propose final words for accepting this. XSH ERN 582. CLOSED
Revisited: Received the following from Andrew G:
Accept this. This becomes AAM for the original ERN.
XSH ERN 583: Ulrich believes this change would make it mandatory for apps to
use getopt(). This is not
the intent of the change, the intent is to say that getopt shall follow the guidelines.
No concensus on how to address this.
ACTION Ulrich Drepper to consider how to address XSH ERN 583
(Don C, Nick, Donn T want to accept).
XSH ERN 596: Defer to Base
ACTION TOG OR to refer XSH ERN 596 to ogtgbase for their consideration
XSH ERN 606: Most of the objection WBO. Would it make sense to have a table of
resources v functions? No. WBO
XSH ERN 611: Although it adds little, it substracts nothing. Leave it alone. Lots of
other functions have similar lead-ins. Reject
XSH ERN 626: WBO
XSH ERN 632: Accept
XSH ERN 633: The text provided replaces the entire description. Leave it open for now.
ACTION ALL to look at this overnight. XSH ERN 633. CLOSED.
New
ACTION Donn Terry to work with Don Cragun to finalize XSH ERN 633.
XSH ERN 645: AAM - must->shall
XSH ERN 646: Lot of discussion on how to wordsmith the stuff given ... revisit later.
XSH ERN 647: Reject. See XBD 4.13, the formula is absolutely crystal clear about
leapseconds. Each and every day since jan 1 1970 has exactly 86400 seconds for the purpose
of calculating seconds since the epoch.
XSH ERN 653: Fred Tydeman - no change required. AAM - we dropped the C99 requirement
that there should be no undue overflow or underflow. Add this back in.
XSH ERN 654: dup 653
XSH ERN 655: dup 653
XSH ERN 664: Accept
XSH ERN 669: Accept
XSH ERN 670: AJ to check with Fred Tydeman: change "too positive" 19831-4 to:
If the correct value is greater than INT_MAX, INT_MAX shall be returned and a domain error
shall occur.
If the correct value is less than INT_MIN, INT_MIN shall be returned and a domain error
shall occur.
XSH ERN 700: Accept
XSH ERN 701: Accept
XSH ERN 702: XBD clearly defines XSH ERN 704: Accept
XSH ERN 705: Accept
XSH ERN 706: Accept
XSH ERN 707: Accept
XSH ERN 710: Accept
XSH ERN 713: dup 670 - AJ to check with Fred Tydeman
XSH ERN 716: AAM - retqain sections
XSH ERN 718: Accept
XSH ERN 728: Accept
XSH ERN 729: Accept
XSH ERN 730: Accept
XSH ERN 731: Accept
XSH ERN 733: Reject - the answer to the question is no.
XSH ERN 734: Accept as marked -- andrew has words.
XSH ERN 754: Accept
XSH ERN 761: Accept
XSH ERN 762: AAM - option 2
XSH ERN 770: Accept
XSH ERN 771: AAM - CX, add to Change history.
XSH ERN 774: Accept
XSH ERN 775: Accept
XSH ERN 776: Accept
XSH ERN 783: Accept
XSH ERN 785: Updated action received from dwc. Using these, make it implementation
defined. Andrew has markup. AAM
XSH ERN 790: Updated action received from dwc. Using these, make it implementation
defined. Andrew has markup. AAM
XSH ERN 791:
XSH ERN 796: WBO - footnotes are not normative, so this is CX
Updated action received from dwc. Using these,
make it implementation defined. Andrew has markup. AAM
XSH ERN 802: Accept
XSH ERN 825: Either is legal english, either is clear, editors discretion; reject
XSH ERN 853: Accept
XSH ERN 881: Accept
XSH ERN 882: WBO.
XSH ERN 884:
Updated action received from dwc. Using these,
make it implementation defined. Andrew has markup. AAM
XSH ERN 893: Reject - from base doc. Interp needed to bring it into scope
XSH ERN 895:
Editors agreed that a global change was appropriate for this and to change Portable
Applications to Conforming Applications. AAM
XSH ERN 899: Mark Brown pleaded for the life of this sentence. Leave it alone. Reject.
Leave it alone
XSH ERN 910: This is a requirement from the Base doc. We have an author in the room
(Frank Prindle) who reckons it was intentionally stated the way it is. It would need an
IR, which would almost certainly have no change resulting. Reject. We should perhaps check
the ftruncate() page.
XSH ERN 954: WBO
XSH ERN 962: Accept
XSH ERN 985: No ... reject. WBO
XSH ERN 993: WBO
XSH ERN 1003: some discussion from Andrew on what the editors notes in the predisposed
aardvark means. Accept
XSH ERN 1019: Defer to BWG
ACTION TOG OR to refer XSH ERN 1003 for their consideration
XSH ERN 1086: AAM - putenv is the only function that can add to the environment
without permitting memory leaks. Add rationale.
XSH ERN 1088: WBO
XSH ERN 1127: Needs base (XNET) work ...
ACTION TOG OR to convey XSH ERN 1127 to ogtgbase for their consideration
XSH ERN 1136: Defer to BWG
ACTION TOG OR to refer XSH ERN 1136 to ogtgbase for their consideration
XSH ERN 1137: Defer to BWG
ACTION TOG OR to refer XSH ERN 1137 to ogtgbase for their consideration
XSH ERN 1141: AAM, use current working directory.
XSH ERN 1142: It is obsolescent -- don't want to touch it! WBO
XSH ERN 1157: WBO
XSH ERN 1190: Accept
XSH ERN 1191: AAM - "five" -> "following" . Do not delete rationale, we like it.
XSH ERN 1196: AAM, split into 2 EINVALS
XSH ERN 1198: Accept
XSH ERN 1200: Accept
XSH ERN 1203: Yes, there's a problem here. Add sigqueue() pthread_kill() to the
function lists on lines 42438 and 42440 (CX shaded). Also change raise -> kill, raise,
sigqueue, pthread_kill on 42439 (appropriately shaded). Still Open ...
POSIX is not more limited than C99 ... why are we adding to the limitiations at all? Why
not remove the (shaded) kill function on 42438 and on 42440?
This has been there for a while.
This would need an IR. Reject.
ACTION Donn Terry to file an IR for XSH ERN 1203 - CLOSED
Donn looked at 1996 std, but could not find a place to make this interp against. Send it
to BWG
ACTION TOG OR to refer XSH ERN 1203 to ogtgbase for their consideration.
ERN is Open.
XSH ERN 1206: Accept
XSH ERN 1212: Accept
XSH ERN 1214: Accept
XSH ERN 1215: AAM use "Single byte character" (Andrew has words)
XSH ERN 1216: Defer to BWG
ACTION TOG OR to refer XSH ERN 1216 to ogtgbase for their consideration
XSH ERN 1217: Defer to BWG.
ACTION TOG OR to refer XSH ERN 1217 to ogtgbase for their consideration
XSH ERN 1218: Defer to BWG
ACTION TOG OR to refer XSH ERN 1218 to ogtgbase for their consideration
XSH ERN 1221: Accept
XSH ERN 1222: AAM - Andrew has notes
XSH ERN 1223: Accept
Also need list from C99 p355 para 3
XSH ERN 1224: AAM (also unshade as he suggests)
XSH ERN 1225: Reject, stick with our conventions
XSH ERN 1228: Accept
XSH ERN 1229: Accept
XSH ERN 1230: AAM, CX shade
XSH ERN 1240: WBO
XSH ERN 1248: Accept
XSH ERN 1249: Accept
XSH ERN 1250: Accept
XSH ERN 1251: Editorial
XSH ERN 1252: Accept
XSH ERN 1254: Editorial
XSH ERN 1255: Accept
XSH ERN 1257: WBO
XSH ERN 1259: Accept
XSH ERN 1267: Accept
XSH ERN 1273: replacement action received from dwc. AAM - use new action
XSH ERN 1275: Defer
ACTION Frank Prindle to propose suitable changes to resolve XSH ERN 1275. CLOSED
AAM, move paragraph only.
XSH ERN 1292: pulled off predisposition list. Need more research
ACTION AJ to research XSH ERN 1275 and propose solution
XSH ERN 1293: pulled off predisposition list. Need more research
ACTION AJ to research XSH ERN 1276 and propose solution
XSH ERN 1296: Accept
XSH ERN 1301: AAM, delete the sentence with the limitation.
XSH ERN 1309: AAM, use CX shading
XSH ERN 1313: Accept
XSH ERN 1316: AAM, (only one the)
XSH ERN 1317: Accept
XSH ERN 1319: Accept
XSH ERN 1331: Accept
XSH ERN 1332: Accept
XSH ERN 1333: Accept
XSH ERN 1334: Accept
XSH ERN 1337: Accept
XSH ERN 1338: This comes from the base docs ... this is better than waitpid(). Donn
realized this one had a snowball's chance in hell ... reject. WBO
XSH ERN 1343: Accept
XSH ERN 1347: AAM - Andrew has words
XSH ERN 1358: Accept
XSH ERN 1368: See 1240 - reject. It is defined on previous page.
XSH ERN 1373: AAM see other rounding aardvark (forgot the number) ... implementation
defined.
XSH ERN 1406: No change is required ... Reject/WBO
XSH ERN 1408: dup 1406; the answer to the question is wide chars.
XSH ERN 1422: Defer to BWG.
ACTION TOG OR to forward XSH ERN 1422 to ogtgbase for their consideration
XSH ERN 1438: We agree with Ed's recommendation to delete intro text, and shallify. AAM
XSH ERN 1440: AAM - Delete 50876-8
XSH ERN 1446: Accept
XSH ERN 1450: Accept
XSH ERN 1451: AAM - see 1450 for rationale and fix.
XSH ERN 1455: Some discussion on the problems of the layout (getting shading correct is a major
issue). Also discussion on the technical problem ... there is no technical problem.
Editors choice on layout ... this is probably as a result of an earlier rearrangement
where it was requested to separate the three functions. Editors will look. AAM
XSH ERN 1456: Accept
XSH ERN 1457: Accept
XRAT ERN 2: Defer to Editors (accept)
XRAT ERN 3: Accept
XRAT ERN 7: Accept
XRAT ERN 9: Defer to collation subgroup
XRAT ERN 10: Defer to collation subgroup
XRAT ERN 13: AAM Editors have markup.
As a result of the 8-bit byte issue, Andrew Gollan submitted the following aardvark to
correct non-8-bit issues. We agreed to accept this (or complain by Monday).
Revisited. Bob Barned submitted email with more detailed list of general requirements for
this, but still largely unspecific in terms of actions to take.
In the case of the number of bits/byte
CS5 and CS6 are not needed.
The baud rates only go up to 38.4K baud.
It should go higher.
There should be a capability of setting
1.5 stop bits.
It may be desirable to be able to specify
the baudrate as a number rather than a constant.
Add ONLCR, OCRNL, ONLRET.
B0 is documented to drop DTR but it's never
specified when (or even if) DTR ever comes back.
What are the interactions between close and a
flow-controlled port?
What about other forms (hardware and software)
of flow control?
What about half-duplex FC?
Is catering to terminals that don't have lower
case (XCASE) still sensible?
How about things like VTDELAY, FFDELAY, VTDELAY etc.
Although much of this stuff is outdated, there are still applications and systems deployed
that use a substantial part of this (including low baud rates and strange number of bits).
We cannot get rid of this at this point.
AAM, as above.
Revisited ... BWG passed a resolution to no longer specify the sin_zero element of the
structure. (also p905 line 14212). AAM
In XCU page 2428 insert after line 8319
Table 4-4 HERE
All implementations shall support an environment where the sizes of the
following types are no larger than the size of an object of
type long:
(alphabetize)
size_t, ssize_t, pid_t, ptrdiff_t, wchar_t, wint_t,
nfds_t, useconds_t, suseconds_t, cc_t, speed_t, tcflag_t,
blksize_t, uid_t, gid_t, id_t
This environment may be one of the ones in Table 4-4, or it may be another
environment. The getconf() name for this environment shall be
_POSIX_V6_SIZE_RESTRICTED. A call to getconf() with this name will return the
name of the environment provided that meets this requirement, which can
then be used in a subsequent getconf() call to obtain the flags specific
to that environment with the following suffixes added as appropriate:
_CFLAGS to get the C compiler flags
_LDFLAGS to get the linker/loader flags
_LIBS to get the libraries
This requirement may be removed in a future version of this specification.
page 2431 after line 8430
Example 4:
The following example shows how an application can use a programming
environment where sizes of the listed types:
(alphabetize)
size_t, ssize_t, pid_t, ptrdiff_t, wchar_t, wint_t,
nfds_t, useconds_t, suseconds_t, cc_t, speed_t, tcflag_t,
blksize_t, uid_t, gid_t, id_t
are no larger than the size of an object of type long:
CENV=$(getconf _POSIX_V6_SIZE_RESTRICTED)
c99 $(getconf ${CENV}_CFLAGS) -D_POSIX_C_SOURCE=200xmmL \
$(getconf ${CENV}_LDFLAGS) foo.c -o foo \
$(getconf ${CENV}_LIBS)
(the xmmL to be filled in).
Add rationale to XRAT page 3381 following line 3271:
[EOVERFLOW] with the restricted programming envir introduced by _POSIX_V6_SIZE_RESTRICTED
several functions may encounter conditions where there is not enough space in the types
in that environment to return the desired result. In that case this error should be raised.
For example functions reurning uid_t or pid_t may return this error.
- a byte is exactly 8 bits;
- CHAR_BIT has the value 8,
SCHAR_MAX has the value 127,
SCHAR_MIN has the value -127 or -128,
and UCHAR_MAX has the value 255.
(Andrew has exact words)
Revisited: AAM, remove the fds_bits[] array on line 12533. Do not free the namespace.
In the namespace reservation table on p488 add sys/select.h in proper alphabetical order,
with fds_ and fd_ and FD_ (add not move from time.h).
Change 12531 ... Andrew has words.
Revisited; AAM - The BWG note that there
is already a symbolic constant required if XSI extensions are supported: _XOPEN_UNIX. See
p22 line 787 and following.
Editorial instructions:
On page 412 move 14274-6 to follow 14561 on p419;
Add unshaded line before 14256 "The following symbolic constant shall be defined only if the
implementation supports the XSI option see 2.4.1"
Delete 14259-14287.
Revisited. Accept
Revisited. This is caused by having 2 shadings on one line. Editors to rephrase to avoid
the problem.
Revisited. Editors will merge the two bullets into one, with an either or. AAM
Revisited.
Based on reflector discussions, Andrew will provide new section
Revisited again (Friday). Cathy has a nicely typeset version of the table. The "os" case
is not defined. It makes no sense to open a socket as a regular file ... this should be a
fail. Linux appears to allow opening, but not reading, from a socket file. The "os" case
should be "-" (implementation defined).
Donn has words for the FL case that better describes symlink actions.
The only remain case is "oa". Streams experts believe that "oa" is the same as "oc".
AAM, add this here and at 11804.
Change 11803-11804:
MRs in a list shall be separated by <blank>s or escaped
<newline>s. An unescaped <newline> shall
terminate the MR list. The escape character is <backslash>.
Revisited: Accept
Revisted: AAM, do as suggested, but also add "The standard action shall be taken
for all other signals, see 1.11 (on p2231)."
AAM: Andrew has words ... unspeicified when partial SIDs are given.
Revisited: AAM, shallified ... Andrew has words.
Revisited: Accept
Revisited. The BWG liked this change, but spent a while wordsmithing the provided text to
shallify and de-normative some parts.
He gives TZ text for delta, same needs to be done for get on p2686 line 18143.
AAM - Andrew has words.
Nick Stoughton noticed in passing that <ESC> should be
<escape-character> on 22910.
However, we notice that cpio does handle sockets, but not tar. Ensure this change
is limited to ustar format.
Revisited:
AAM - changes are needed to admin and delta to warn that the max lines recorded in the
file is 99999; p2343, line 4831-4833 add new para after first sentence. Add a new sentence
to the end of the second para thus formed "If this file contains more than 99999 lines,
the number of lines recorded in the header for this file shall be 99999 for this delta".
Also on p2523, line 11836 add same sentence at end. In prs, take action given in aardvark.
Revisited: Accept
Revisited. Rejected. The current definition is as intended. If there are 10000 pseudo ttys
all with getty (yes, we know getty is not in the spec) waiting to run a login, this will
list all 10000. This is intended.
Revisited again...Donn has comments on the BWG response.
This is not fully responsive to my objection; if the implementation had a large
number of terminal lines, then it would make sense for who -l to list them all.
However, if "waiting for" means "could log in on" then the number is potentially
unbounded (due to ptys). If it's intended that it's only ports on which a getty
(more or less) is active, it doesn't quite say it, at least to me.
Revisited.
What Bob asks for is already done for the 7 attributes objects herein defined.
Technically, this is an accept.
However, the semantics of using an attributes object after it is destroyed,
and of initializing an attributes object that is already initialized, are
described differently (in combination) for virtually every one. Witness:
------------------------------------------------------------------------------
DESTROY description:
pthread_attr:
The behavior of using the attribute after it has been destroyed is undefined.
<should be "attributes object", not attribute>
pthread_condattr:
pthread_mutexattr:
A destroyed <attribute-kind> attributes object can be re-initialized using
<attribute-name>_init(); the results of otherwise referencing the object after
it has been destroyed are undefined.
posix_spawnattr:
pthread_rwlockattr:
pthread_barrierattr:
The effect of subsequent use of the object is undefined until the object is
reinitialized by another call to <attribute-name>_init().
posix_trace_attr:
The results of using the attributes object after it has been destroyed are
unspecified. A destroyed <attribute-kind> attributes object can be
reinitialized using <attribute-name>_init().
<"unspecified" -> "undefined"?>
------------------------------------------------------------------------------
INIT description:
pthread_attr:
pthread_mutexattr:
posix_spawnattr:
The effect of initializing an already initialized <attribute-kind> attributes
object is undefined.
posix_trace_attr:
The effect of initializing an already-initialized <attribute-kind> attributes
object is unspecified.
<"unspecified" -> "undefined"?>
pthread_condattr:
Attempting to initialize an already initialized <attribute-kind> attributes
object results in undefined behavior.
pthread_rwlockattr:
pthread_barrierattr:
Results are undefined if <attribute-name>_init() is called specifying an
already initialized <attribute-kind> attributes object.
------------------------------------------------------------------------------
I suggest substituting the following common wording:
In destroy:
A destroyed <attribute-kind> attributes object can be re-initialized using
<attribute-name>_init(); the results of otherwise referencing the object after
it has been destroyed are undefined.
In init:
Results are undefined if <attribute-name>_init() is called specifying an
already initialized <attribute-kind> attributes object.
------------------------------------------------------------------------------
In order to accept this, we have to accept a change to .1q from unspecified
to undefined.
In order to accept this, we have to accept a change to .1c from "using the
attribute after it has been destroyed" to "using the thread attributes object
after it has been destroyed".
Is it in our scope to make these two changes without interp requests?
Frank
AAM - Andrew has markup.
Revisited. Frank received mail from Michael Gonzalez claiming that the interp was
referred to sponsor. Andrew J as interps chair states that this IR has not
been finalized.
He will will send out a proposed draft of the IR for voting. It is controversial.
Revisited.
Received from Andrew Gollan:
@ Page XXX Line XXX8 Section Comment []
Problem:
We mention Protocol Families, when we should only mention Address
families.
Action:
On page 292 lines 10171&10195 change protocol -> address.
On page 903 lines 14129&14150 change protocol -> address.
On page 904 line 14158 change PF_ to AF_.
On page 904 lines 14186-14190 change protocol family -> address family.
On page 2199 delete line 859
Replace sections 2.10.1-3 on pages 530-531 with:
2.10.1 Address Families
All network protocols are associated with a specific address
family. An address family provides basic services to the protocol
implementation to allow it to function within a specific network
environment. These services may include packet fragmentation and
reassembly, routing, addressing, and basic transport. An address
family is normally comprised of a number of protocols, one per
socket type. Each protocol is characterized by an abstract socket
type. It is not required that an address family support all
socket types. An address family may contain multiple protocols
supporting the same socket abstraction.
Section 2.10.17 (on page 538), Section 2.10.19 (on page 539),
and Section 2.10.20 (on page 539), respectively, describe the
use of sockets for local UNIX connections, for Internet protocols
based on IPv4, and for Internet protocols based on IPv6.
2.10.2 Addressing
An address family defines the format of a socket address. All
network addresses are described using a general structure, called
a sockaddr, as defined in the Base Definitions volume of IEEE
Std 1003.1-200x,
Revisited. Received from Donn:
Replace 14646 ("none") with:
This function is aligned with the C99 standard, and in doing so a few
"obvious" things
were not included. Specifically, the set of characters allowed in a scanset
is
limited to single-byte characters. In other similar places, multibyte
characters have
been permitted, but for alignment with C99, it has not been done here.
Applications
needing this could use the corresponding wide-character functions to achieve
the
desired results.
@ Page 798 Line 10670-10676 Section Comment []
Problem:
There are meaningless references to a STREAMS file where a pipe
could easily be used.
Action:
On lines 10670-10676 change all occurrences of "STREAMS file" to
"STREAM".
@ Page 290 Line 10129 Section Comment []
Problem:
We need a new EAI_ errno to handle truncation of returned information
from getnameinfo().
Action:
On page 290 After line 10129 add a new line:
"EAI_OVERFLOW an argument buffer overflowed."
On page 905 after line 14229 add a new line:
"[EAI_OVERFLOW] An argument buffer overflowed."
If this action is not completed by Monday, this becomes an Accept.
Revisited.
ACTION Don Cragun to finalize wording for XSH ERN 646.
AGREED Leap seconds, or any other adjustment mechanism, are not part of the mechanism for
calculating "seconds since the Epoch", and that any corrections to match adjustments in
official time in an implementation are implementation defined.
@ Page 127,129,136,1487,2459,3175,3180 Line
3989,4094,4329,31469,9509,36892,37070 Section many Normative References
Comment
Problem:
There are invalid references to bytes != 8 bits.
Action:
On page 127, line 3989 remove ", larger bytes"
On page 129, line 4093 remove the sentence beginning "Implementations
supporting..."
On page 136, delete lines 4328-4329.
On page 1487, line 31469, change 8-bit -> 8-bits, 16-bit -> 16-bits (first
one).
On page 2459, delete lines 9509-9513.
On page 3180, delete lines 37070-37073.
Draft 6 should be issued April 20. Looking at a thirty day recirculation and three day meeting (maybe four). Most feel that four days is better. Meeting planned for 5/29-6/1. Draft 7 planned for Jun 15.
The problem is the relationship between atexit() and dlopen() [and dlclose()]. Should atexit registered funcs be called on dlclose.
Should the behavior be run in dlcose,, or wait till exit? If wait till exit, is undefined behavior allowed? Implementation defined either on dlclose or on exit. Or make dlopen'ed modules forbidden to use atext.
General preference was for dlclose, but still need to check with other experts. Implementation defined is fallback position. ACTION Mark Brown to provide feedback on atexit() problem by Tuesday 3/13/01
There is a pending IR from Ulrich. Dave Butenhof has responded, and has suggested wording.
This needs finalizing.
ALL Interps need to be in the pipeline this week to have a hope of finalizing in time.
Received additional comments from DWC:
In SUSv2's kill utility and trap shell special built-in, signal numbers were marked obsolescent. As per plan, the obsolescent features were removed from Austin Group draft 1. Due to common usage on XSI conforming implementations, the use of signal numbers for the trap special built-in was reinstated as an XSI extension in draft 2. But, the symmetry provided between kill -signal_number and trap "action" signal_number was lost. A late arriving aardvark item (austin-review-l email sequence number 876, submitted by Andries Brouwer) pointed out that some references to the obsolescent -signal_name and -signal_number options were still present in Austin Group XCU draft 5. The Action specified in the aardvark comment in email sequence number 876 suggested adding the obsolescent synopsis lines back onto the kill page, but did not suggest reinstating the descriptions of the obsolescent options. For symmetry with the trap special built-in utility and to support numerous shell scripts that run on UNIX '95- and UNIX '98-conforming implementations, the following changes should be made in response to the aardvark item submitted in email sequence number 876: Copy all OB shaded text from SUSv2's XCU5, P418-419 into the appropriate places in Austin Group's XCU6, draft 5, P2737 as XSI shaded text, except: Change "in the obsolescent form" in the addition to the first paragraph of the OPTIONS section to "in the last two synopsis forms". Change the last paragraph of the options section to be: "If the first argument is a negative integer, it shall be interpreted as a -signal_number option, not as a negative pid operand specifying a process group." Add the line: kill -9 100 -165 before XCU6, draft 5, P2739, L20096 in the Examples. Delete XCU6, draft 5, P2739, L20118-20119 in the Examples. (This is modified and moved to Rationale below.) Add a new paragraph to Rational in XCU6, draft 5, P2740, L20139: "To avoid an ambiguity of an initial negative number argument specifying either a signal number or a process group, IEEE Std 1003.1-200x mandates that it is always considered the former by implementations that support the XSI option. It also requires that conforming applications always use a "--" options terminator argument when specifying a process group, unless an opton is also specified." Change XCU6, draft 5, P2740, L20155 in the Change History to: "The obsolescent versions of the synopsis were turned into non-obsolescent features of the XSI option corresonding to a similar change in the trap special built-in."Accepted.
This is still an issue! One solution is to add EOVERFLOW to the shall fail list of errors. This is acceptable. For both ftw and nftw add "EOVERFLOW A field in the stat structure cannot be represented correctly in the current programming environment for one or more files found in the file hierarchy." to shall fail.
Also make both ftw and nftw non-thread safe. The results are unspecified if the application supplied function does not preserve the current working directory.
The ISO ballot closed with 1 negative and 3 approve with comments
(and 6 approve no comments).
The negative was from Canada, and is a procedural issue. This is covered
explictly by the JDOCs procedures (which Canada was instrumental in
producing); these procedures have been approved by WG15. The final version
of the document (draft 7) will be available for DIS ballot in June. The
development process is open to all, and all technical canadian comments
received between draft 4 and draft 7 have been and will be reviewed
extensively and integrated as appropriate. The ISO document editor
believe that this is sufficient to address the Canadian concerns.
USA Comments: Thank you for your comments, we will do this. Accepted.
Norwegian Comments:
The name is stored in a troff macro that is used throughout the
document. Until it is an approved ISO standard, it is not usual to
use the ISO name (see all other POSIX standards produced through the
IEEE process). However, on adoption, the name used throughout will be
ISO/IEC 9945-1.
UK comments. Accept.
We have a fundamental disagreement as to whether these WIDTH* statements belong in charmap or locale. Keld wants to support them in both places. Other people here (and elsewhere) strongly believe this can only be in the charmap (Gary Miller, Ulrich Drepper, Don Cragun). There is no known industry practice to place these in the locale. Keld argued his point again. Ulrich believes the only people helped by this are specification writers, not implementors or app developers. The width of a character depends entirely on the encoding, not the locale. Duplication will lead to further problems, discrepancies, etc. Keld believes his solution better, others disagree.
The meeting adjourned at 1.03pm friday.