Document Number: AUSTIN/32r1
Title: XBD D1 Aardvark Change Request Report Final
Revision Date: 1999-10-29
Source: Andrew Josey, Chair
Action: for information
This report contains the dispositions of the aardvark comments
submitted against the XBD Draft 1.
Aardvark Summary Table
______________________
ERN 1 Duplicate of 21
ERN 2 Accept
ERN 3 Accept
ERN 4 Duplicate of 7
ERN 5 Duplicate of 7
ERN 6 Accept as marked
ERN 7 Accept
ERN 8 Accept
ERN 9 Duplicate of 7
ERN 10 Accept
ERN 11 Accept
ERN 12 Accept
ERN 13 Accept
ERN 14 Accept
ERN 15 Accept
ERN 16 Accept as marked
ERN 17 Accept
ERN 18 Accept
ERN 19 Accept as marked
ERN 20 Reject
ERN 21 Accept as marked
ERN 22 Accept as marked
ERN 23 Duplicate of 22
ERN 24 Accept as marked
ERN 25 Accept
ERN 26 Accept as marked
ERN 27 Reject
ERN 28 Accept
ERN 29 Accept
ERN 30 Accept as marked
ERN 31 Accept as marked
ERN 32 Reject
ERN 33 Accept
ERN 34 Accept
ERN 35 Accept
ERN 36 Reject
ERN 37 Reject
ERN 38 Accept as marked
ERN 39 Duplicate of 40
ERN 40 Accept as marked
ERN 41 Reject
ERN 42 Duplicate of 16
ERN 43 Duplicate of 16
ERN 44 Accept
ERN 45 Duplicate of 16
ERN 46 Accept
ERN 47 Accept as marked
ERN 48 Accept as marked
ERN 49 Reject
ERN 50 Accept
ERN 51 Duplicate of 49
ERN 52 Accept as marked
ERN 53 Accept as marked
ERN 54 Accept
ERN 55 Accept
ERN 56 Accept as marked
ERN 57 Accept
ERN 58 Accept as marked
ERN 59 Reject
ERN 60 Accept
ERN 61 Accept
ERN 62 Accept as marked
ERN 63 Accept as marked
ERN 64 Accept
ERN 65 Duplicate of 67
ERN 66 Accept
ERN 67 Accept as marked
ERN 68 Duplicate of 46
ERN 69 Accept
ERN 70 Accept
ERN 71 Accept
ERN 72 Accept
ERN 73 Accept as marked
ERN 74 Accept as marked
ERN 75 Accept as marked
ERN 76 Accept as marked
ERN 77 Accept as marked
ERN 78 Duplicate of 77
ERN 79 Accept
ERN 80 Accept
ERN 81 Accept as marked
ERN 82 Accept
ERN 83 Accept as marked
ERN 84 Reject
ERN 85 Accept as marked
ERN 86 Accept
ERN 87 Accept as marked
ERN 88 Accept as marked
ERN 89 Accept as marked
ERN 90 Accept
ERN 91 Accept
ERN 92 Accept
ERN 93 Duplicate of 94
ERN 94 Reject
ERN 95 Accept
ERN 96 Accept as marked
ERN 97 Reject
ERN 98 Accept as marked
ERN 99 Accept as marked
ERN 100 Accept as marked
ERN 101 Accept as marked
ERN 102 Reject
ERN 103 Reject
ERN 104 Reject
ERN 105 Accept
ERN 106 Accept as marked
ERN 107 Accept
ERN 108 Accept as marked
ERN 109 Accept
ERN 110 Accept
ERN 111 Accept
ERN 112 Accept as marked
ERN 113 Accept as marked
ERN 114 Accept
ERN 115 Duplicate of 114
ERN 116 Accept
ERN 117 Accept
ERN 118 Accept
ERN 119 Accept as marked
ERN 120 Accept as marked
ERN 121 Accept
ERN 122 Accept as marked
ERN 123 Accept
ERN 124 Accept
ERN 125 Accept as marked
ERN 126 Accept as marked
ERN 127 Accept
ERN 128 Accept as marked
ERN 129 Accept as marked
ERN 130 Accept
ERN 131 Accept
ERN 132 Accept
ERN 133 Accept
ERN 134 Accept
ERN 135 Accept as marked
ERN 136 Accept as marked
ERN 137 Accept
ERN 138 Accept as marked
DETAILED DISPOSITIONS.
_____________________________________________________________________________
comment Enhancement Request Number 1
nick@usenix.org Bug in XBD (rdvk# 2)
{2} Sat Jun 5, 12:39am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_21_ Reject_____
Rationale for rejected or partial changes:
dup of 21
_____________________________________________________________________________
Page: 0 Line: 0 Section: 0
Problem:
What is XSI?
We have introduced the terms XBD, XSH and XCU (and XRAT for that
matter), but this document is full of references to "XSI-Conformance"
and extensions for XSI, without any explanation.
Action:
Add an introductory section describing XSI.
_____________________________________________________________________________
editorial Enhancement Request Number 2
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 43)
[DWC-XBD-1] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 0 Line: 0 Section: 0
Problem:
(American vs. English)
If this is an IEEE document, it should use American English spelling. If it
is a TOG document, it should use British English spelling. (I believe ISO
documents could go either way.) Given that this is an Austin Group document,
I don't know which spelling should be used.
Action:
If this is intended to be a document developed in the US, convert "catalogue"
(on Pxv, L564) and other British spellings in this document to "catalog" and
other American spellings.
If this is intended to be a document developed in the UK, convert
"standardization" (on Pii between lines 11 and 12) and other American
spellings in this document to "standardisation" and other British spellings.
(Note that it will be much easier to convert the entire document to American
English than to convert it to British English.)
_____________________________________________________________________________
editorial Enhancement Request Number 3
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 44)
[DWC-XBD-2] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Done by the editors as part of the style cleanup
_____________________________________________________________________________
Page: 0 Line: 0 Section: 0
Problem:
(representation of explicit characters)
In draft 1 of this document set, references to explicit characters (such as
'\a') and strings (such as "...") in this draft do not use the quotes to
delimit them as they appeared in POSIX.1 and POSIX.2. The lack of quotes that
explicitly delimit the C language character constants and strings makes it
harder for programmers to interpret the standard's requirements. It also
makes it harder for non-programmers to parse some statements. (It is
sometimes hard to distinguish literal quotes, parentheses, and brackets with
grouping quotes, parentheses, and brackets.) In some cases (such as P107,
L3399) it creates an ambiguity in the requirements. (The definition here
seems to say that an ellipsis is two periods instead of three periods.)
Action:
Change "\a" on P6, L135 to "'\a'".
Change 'The string ...' on P107, L3399 to 'The string "...".'.
Globally change other uses of explicit references to characters to enclose
them in single quotes.
Globally change other uses of explicit references to strings of characters to
enclose them in double quotes.
_____________________________________________________________________________
comment Enhancement Request Number 4
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 45)
[DWC-XBD-3] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_7 Reject_____
Rationale for rejected or partial changes:
dup of 7
_____________________________________________________________________________
Page: xv Line: 449-565 Section: Preface
Problem:
(TOG, IEEE, & ISO)
Given that this is a joint development group, we either need to delete the
discussion on The Open Group or add discussions on IEEE and ISO/IEC.
Action:
Either delete Pxiii-xv, L449-565 or add sections describing IEEE and ISO/IEC
similar to the way the current contents describe The Open Group.
_____________________________________________________________________________
Objection Enhancement Request Number 5
donn@interix.com BUG in XBD (rdvk# 7)
[] Fri, 25 Jun 1999 11:26:04 -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_7_ Reject_____
Rationale for rejected or partial changes:
dup of 7
_____________________________________________________________________________
Page: xii Line: 450 Section: Preface
Problem:
This will need to be completely rewritten to meet ISO style rules
and to acknowledge the Austin group (rather that TOG) participation.
Action:
Depends on results of negotiations. This should be kept as an
unresolved objection for the time being.
_____________________________________________________________________________
objection Enhancement Request Number 6
donn@interix.com Bug in XBD (rdvk# 6)
[] Tue Jun 15, 10:06am -0600
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The style changes identified at the Montreal meeting are being
implemented in this next draft. Layout and other style
discussions with IEEE are ongoing and will be closed out before the
next draft.
The editors have got feedback from IEEE/ISO on the layout.
Manual pages have been confirmed as ok. We have made other
changes as per the output of the montreal meeting.
_____________________________________________________________________________
Page: xiii Line: 450 Section: Preface
Problem:
This objection really applies across the board to many others, and
falls into the "for the record" category, at the moment.
I have NOT seen any details of any discussions between the formal
standards bodies and the Austin Group, so some of this may have
been addressed. However, I cannot emphasize strongly enough that
based on past experience, the formal standards buracracy is not to
be taken lightly. The original 1003.1 would have looked a great
deal different had it not been for the insistence on the application
of formal rules and a need for consistency of style with other
standards.
It took months of negotiation to get line numbers approved by the
ITTF, and then one (important) national body voted negative on each
and every POSIX ballot because of line numbers (and some other
style things), no matter whether they were informed that the issue
had been resolved. This negative ballot came not from the technical
experts, but from that national body's buracracy.
It would be naive to think that the current style has much of a
chance of being approved without significant modification, and if
the issues have not been resolved, there's little chance that this
effort will result in an approved IEEE, National, or International
standard.
In some sense, this has to be considered the single most important
objection: if the document cannot be approved as formal standard,
then why bother at all?
Please don't get me wrong: In general I find the current document
an improvement (particularly in organization, although the author
of the present POSIX organization might not agree). Most of the
things that are likely to stand in the way of approval are NOT
related to that, but at a finer level of detail:
1) Requirements for stilted language, particularly the use of "shall".
(This exists for two reasons: the obvious English usage of the
imperative form, in the case of shall, but also a number of
issues w.r.t. assuring that translations are accurate and
unambiguous. I'm not enough of an expert, but can the subtleties
of can/may/shall/should be accureately rendered into all of
French, Russian and Japanese, the three additional ISO languages
besides English?)
2) Requirements of form to match the ISO "house style".
The IEEE was gracious enough to yield to most of the requirements
of ISO style, while still going to bat for us on a few really
important issues such as line numbers. However, my informal
impression of the situation up and down the standards buracracy
was "here's a bunch of whipper-snappers (again!) who think they
know better than we do what makes a good standard". Going through
that again would be tedious and probably introduce at least a year
delay (as it did last time), so we need to start NOW on working
through the style issues, and making the required style corrections
in early drafts, so it's right in the later ones.
Again, let me empahsize that there are good reasons behind some of
the ISO rules (and nonsense behind others). We should be sure that
we DO keep the good reasons, and fight only those battles which
are truly important, because we'll win only a few, and those few we
choose to fight will themselves provide a significant delay in the work,
particularly if they are serialized with the technical work.
Action:
1) Arrive at an acceptable (to ISO) style for the document
IN TIME FOR DRAFT 2.
2) Convert the document to that style.
_____________________________________________________________________________
Comment Enhancement Request Number 7
ajosey@opengroup.org Bug in XBD (rdvk# 28)
[TOG-XBD-001] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xii Line: 450 Section: Preface
Problem:
rdvk #7 from donn@interix.com raises an objection to the
preface. The reviewers notes state that this is a left over
from the Base documents. At the time of production of draft 1
the project had not been approved as an IEEE project.
The preface will be replaced with a new preface later in the project
(completion due by draft 3)
Action:
Leave it to the editors to resolve as already noted in the reviewers
note
_____________________________________________________________________________
Editorial Enhancement Request Number 8
donn@interix.com Bug in XBD (rdvk# 8)
[] Mon Jun 28, 9:28am -0600
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 1 Line: 19 Section: 1.2
Problem:
We can't be sure how the application will use it, just how it can be used.
Action:
"it is used" -> "it can be used".
_____________________________________________________________________________
editorial Enhancement Request Number 9
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 46)
[DWC-XBD-4] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_7 Reject_____
Rationale for rejected or partial changes:
dup of 7
_____________________________________________________________________________
Page: xvi Line: 569-571 Section: Preface
Problem:
(Issue number)
This is XBD6, not XBD5.
Action:
Change "Issue 5" on Pxvi, L569 to "Issue 6".
Change "Issue 5" on Pxvi, L570 to "Issue 6".
Change "Issue 5" on Pxvi, L571 to "Issue 6".
_____________________________________________________________________________
comment Enhancement Request Number 10
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 47)
[DWC-XBD-5] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xviii Line: 633 Section: Trademarks
Problem:
(unused trademarks)
I didn't find any uses of "Openview" in this document set, except listing it
as a registered trademark.
Action:
Remove trademarks that are not used in this document set (other than to list
them as trademarks) from the Trademarks page.
_____________________________________________________________________________
comment Enhancement Request Number 11
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 48)
[DWC-XBD-6] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xix Line: 644-647 Section: Acknowledgements
Problem:
(IEEE acknowledgement)
Given that this document is being jointly developed by IEEE, and ISO/IEC, TOG,
I don't see why we need to acknowledge IEEE or IEEE CS PASC any more than we
need to acknowledge ISO or TOG contributions.
Action:
Delete Pxix, L644-647.
_____________________________________________________________________________
comment Enhancement Request Number 12
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 49)
[DWC-XBD-7] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xx Line: 655-657 Section: Referenced
Problem:
(Referenced Documents)
This paragraph needs to be rewritten so it works in IEEE and ISO standards as
well as in TOG Technical Standards.
Action:
Change Pxx, L655-657 to:
The following documents are referenced in this document set:
_____________________________________________________________________________
comment Enhancement Request Number 13
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 50)
[DWC-XBD-8] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xxiii Line: 658-818 Section: Referenced
Problem:
(Referenced Documents)
I haven't verified this, but I can't believe that all of the documents in this
section are actually referenced in XBD6, XCU6, or XSH6.
Action:
Check all of documents listed here and remove entries for each document that
is not referenced in XBD6, XCU6, or XSH6.
I won't mind if this action is deferred until a decision is made as to whether
XNS will be merged into this document set. But, this has to happen before
this document set is adopted.
_____________________________________________________________________________
objection Enhancement Request Number 14
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 51)
[DWC-XBD-9] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xxi Line: 737,738 Section: Referenced
Problem:
(Issue number)
This document is part of Issue 6, not Issue 5.
As an Austin Group document (rather than a TOG document), TOG documents
shouldn't be segregated from other documents.
Action:
Delete Pxxi, L736-738 and merge the lists before and after this paragraph into
a single sorted list.
_____________________________________________________________________________
editorial Enhancement Request Number 15
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 52)
[DWC-XBD-10] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: xxii Line: 763-765 Section: Referenced
Problem:
(Referenced Documents)
The entries in the Referenced Documents list should be in alphabetic order.
XNS should follow XBD, XCU, and XNFS.
Action:
Move Pxxii, L763-765 to follow Pxxiii, L798.
_____________________________________________________________________________
comment Enhancement Request Number 16
Frank Bug in XBD (rdvk# 106)
[prindle.xbd-2] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
We need to have consistent names for individual volumes and a consistent
way to refer. No specific action required for this one item, but editors
agree to take this approach for specifics as they occur.
_____________________________________________________________________________
Page: 2 Line: 62 Section: 1.3
Problem:
I understand that the "names" of these specifications are really not well
defined yet, so this comment is a place-holder. I assume that throughout the
document, the terms "the XCU specification", "the XSH specification", "the XBD
specification", etc. are used consistently (for now) for self/cross reference
among the draft documents.
Action:
When the ultimate long and short names are decided, replace all occurences of
these current spec names with the agreed upon short name. For example, "the XCU
specification" on this page might be "POSIX.2".
-------------------------------------------------------------------------------
_____________________________________________________________________________
comment Enhancement Request Number 17
Frank Bug in XBD (rdvk# 105)
[prindle.xbd-1] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 2 Line: 71-73 Section: 1.3
Problem:
This text is a bit confusing as it stands.
Action:
Change "the description is marked." to "the description is marked with the OF
code and shading." and join lines 72-73 into the same paragraph after this
sentence.
-------------------------------------------------------------------------------
_____________________________________________________________________________
objection Enhancement Request Number 18
Frank Bug in XBD (rdvk# 108)
[prindle.xbd-4] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3 Line: 74-112 Section: 1.3
Problem:
The set of codes documented here differ from the sets of codes documented in
the corresponding section of XSH and XCU. I would expect XBD to be the official
document defining all codes, with these repeated verbatim in XSH and XCU only
for convenience.
Action:
Include all codes which apply to any of XBD, XSH, or XCU here. Do not include
these codes at all in XSH or XCU -or- (for convenience of the reader) include
the exact same code descriptions in XSH and XCU, indicating that these are
identical to those in XBD and reproduced for convenience; it is permissible in
XSH and XCU to omit codes which do not appear in the particular spec, though
I suspect this would be more trouble than it is worth (in keeping the docs
sync'ed).
-------------------------------------------------------------------------------
_____________________________________________________________________________
Objection Enhancement Request Number 19
donn@interix.com BUG in XBD. (rdvk# 99)
[] Thu Jul 1, 10:13am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Create a definition in the definitions chapter for XSI, and add
a cross reference to that definition in the codes section.
_____________________________________________________________________________
Page: 3 Line: 77 Section: 1.3
Problem:
And to respond to Andrew's comments:
If a term is used in XBD, it should be defined there.
If a term is used in more than one of the other volumes it should
be defined in XBD, so there is only one definition.
(As we have found from experience, any time there are two of anything
normative, one will get out of sync, sooner or later.)
This specifically applies to the XSI notation, as well as several of the
others (probably all, but???).
If the documents are to be read as a single set, then knowing that
all definitions are in XBD makes them easier to find. (Or are we going
to do a single index spanning all 3 logical and (probably) 5 physical
volumes. Or will that be another volume itself?)
(No... I wouldn't object to a non-normative short summary of the notations
in the other volumes, but keep the official stuff in one place.)
Action:
The definition of XSI (etc) should be moved here.
_____________________________________________________________________________
Objection Enhancement Request Number 20
donn@interix.com Bug in XBD (rdvk# 9)
[] Mon Jun 28, 9:28am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_
Rationale for rejected or partial changes:
see problem statement in 21 for rationale
_____________________________________________________________________________
Page: 3 Line: 77 Section: 1.3
Problem:
Similarly to someone else's objection "XSI" is not only undefined,
but a strange mnemonic (carrying over from the days of X/Open).
Does it even apply any longer, or should all instances of it either
be made normal parts of the document or discarded? (There's nothing
preventing a profile, such as the SUS, from restoring omitted
elements.)
Action:
Delete the string "XSI" everywhere, and resolve the features to either
be in or out of the new standard. (Similarly for all other such notations
that represent leftovers from this document being a profile of POSIX.)
_____________________________________________________________________________
Objection Enhancement Request Number 21
ajosey@opengroup.org Bug in XBD (rdvk# 29)
[TOG-XBD-002] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Place extracts from the problem statement on why XSI is needed into
rationale.
Don't take the action from here, but implement the action in ERN #19.
_____________________________________________________________________________
Page: 3 Line: 77 Section: 1.3
Problem:
This is an objection to rdvk #9 from donn@interix.com.
The proposed action misunderstands some of the basic principles
of the project.
A couple of points to note about the XSI notation and organization
of the document set.
(i) These documents are to be read as a set - they are
one logical document , there is one approved PAR. The splitting into
the existing physical volumes is a publishing matter (note that the
XSH is most likely to be published in a two volume set).
The definition of XSI at the moment is described in XSH/XCU in the
conformance section. It does seems clear that we need to have some
description/cross reference at a minimum in XBD to the conformance
sections where this is spelt out. The proposed replacement action
below suggests one.
(ii)Onto why XSI? For now, It has been assumed that
POSIX conformance would not equate to UNIX conformance for these
Base volumes.
XSI is used to describe the extensions over POSIX for conformance
requirements for the Single UNIX Specification.
See the diagram in the reviewers note and the conformance section
in XSH and XCU for an understanding of XSI.
The term XSI has been used for 10 years in connection with the XPG
series and the first and second versions of the base volumes of
the Single UNIX Specification.
XSI, refers to the X/Open System Interface, that is the application
programming interface for C and sh programming.
(iii) These documents are to act as both an IEEE standard and
an Open Group technical standard.
There would be one core set of documents - the note in the problem
statement suggesting the Single UNIX Spec to split its base documents
would be a major divergence from the intended goal of the project.
New functionality is being considered for merging into the POSIX base (the
initial suggestions have a reviewers note at the top of the man pages
in XSH, or are marked MAN on the man page),
but until all is merged, we need to retain a marking (or markings)
for extensions.
(v) The action statement also says "(Similarly for all other such notations
that represent leftovers from this document being a profile of POSIX.)"
This needs to be specific. Which "other such notations"?
The notations UP,OP,PI,UN are already stated in the long scope
as being subject to review , with a view to resolving the text
so they are not needed.
Notations such as SHM are for POSIX options.
Without specifics this is impossible to action, even if it were
to be agreed.
Action:
Reject rdvk #9 from donn@interix.com (suggesting removal of all XSI markings)
Add text cross referencing the XSH/XCU specifications
at the first use of XSI (page 3 line 76) as follows:
Change "The functionality described is an XSI extension." to
"The functionality described is an XSI extension (see section
2 of XSH, and section 2 of XCU for a description of the X/Open
System Interface extension. )."
_____________________________________________________________________________
editorial Enhancement Request Number 22
nick@usenix.org Bug in XBD (rdvk# 1)
{1} Sat Jun 5, 12:39am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
delete 82-86, since the POSIX options are now marked as such
this statement is no longer true, its a left over from XSH5.
_____________________________________________________________________________
Page: 3 Line: 82 Section: 1.3
Problem:
"Some optional POSIX System Interfaces behavior is mandated on
conforming systems. Such behaviors (for example, those dependent on the
availability of mapped files) might not be individually marked as
extensions, but the mandatory nature of the feature is marked as an
extension where the option is described, typically in the header where
the corresponding symbolic constant is defined."
This is poor English, and very hard to parse and understand. Further it
is not at all obvious when you read this why we have mandatory options!
It even uses a new term, not defined earlier "might" ... :-(
Action:
Replace with:
For some POSIX System Interfaces, optional behavior is mandated on
conforming systems. However, profiles of this \*(St need not mandate
this behavior. Such behavior (for example, behavior dependent on the
availability of mapped files) is not individually marked as an
extension, but the mandatory nature of the feature is marked as an
extension where the option is described, typically in the header where
the corresponding symbolic constant is defined.
_____________________________________________________________________________
comment Enhancement Request Number 23
evought@qlue.com Bug in XBD (rdvk# 121)
{[QCI 1]} Wed, 14 Jul 1999 13:50:07 +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_22 Reject_____
Rationale for rejected or partial changes:
dup of 22
_____________________________________________________________________________
Page: 3 Line: 82-86 Section: 1.3
Problem:
This paragraph is difficult to follow and not well written (even
when taking into account action in aardvark #19). This comment
is compatible with the action in aardvark #19 and should be used
in conjunction with it.
I think that this change will make the intent of the paragraph more
clear.
Action:
Change the sentence:
Such behavior (for example, behavior dependent on the
availability of mapped files) is not individually marked as an
extension, but the mandatory nature of the feature is marked as an
extension where the option is described, typically in the header where
the corresponding symbolic constant is defined.
with:
Such behavior (for example, behavior dependent on the availability
of mapped files) is not individually marked as an extension but
the mandatory nature of the underlying feature is indicated by
labelling it as an extension where the option is described,
typically in the header where the corresponding symbolic
constant is defined.
_____________________________________________________________________________
objection Enhancement Request Number 24
Frank Bug in XBD (rdvk# 107)
[prindle.xbd-3] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The aim is to get rid of OP markings and remove the code once its no
longer used.
The editors will search for use of OP in all three volumes and once
gone remove it. The second part of this action is covered by ERN #18.
_____________________________________________________________________________
Page: 3 Line: 99-101 Section: 1.3
Problem:
The code OP no longer appears to be used in XSH or XCU, having presumably been
replaced by the SPECIFIC option code on which the functionality is dependent.
Also, unlike XSH and XCU, there is no reference here to the additional codes
for specific options. I think it would be best if one did not have to look in
multiple places for codes, but that ALL codes should be introduced here (I have
no problem with them being repeated as they are now in section 2.1.6 of XSH and
XCU).
Also note that some specific option codes are referenced within XBD, and thus
rightly belong here. An example is SHM which appears on page 31, line 757.
Action:
Remove these lines. Instead, list and describe in this section all codes for
specific options, thereby creating a master reference for margin codes.
-------------------------------------------------------------------------------
_____________________________________________________________________________
editorial Enhancement Request Number 25
Frank Bug in XBD (rdvk# 109)
[prindle.xbd-5] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 6 Line: 156-157 Section: 2.12
Problem:
When the phrase "the XSH specification" or "the XCU specification" is used
elsewhere, the XSH and XCU is not BOLD.
Action:
Everywhere these phrases are used, make XSH, XCU, XBD bold, consistently. Or,
as the seems to add little value and these phrases will eventually be replaced
by the agreed-upon short name for the standards, eliminate the bold altogether.
-------------------------------------------------------------------------------
_____________________________________________________________________________
Comment Enhancement Request Number 26
donn@interix.com BUG in XBD (rdvk# 10)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
An action has been assigned to HPA to provide text showing a mapping
between the name used in the text and official ISO 10646 names.
_____________________________________________________________________________
Page: 7 Line: 171 Section: 2.16
Problem:
Are all the character names (this is just the first one I noticed)
in complete correspondence with the corresponding ISO standards? If
so, say so somewhere. If not, they will need to be before the standard
can be approved for ISO.
Action:
(Presumably someone just knows which is true): fix as noted.
_____________________________________________________________________________
Comment Enhancement Request Number 27
ajosey@opengroup.org Bug in XBD (rdvk# 30)
[TOG-XBD-003] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_
Rationale for rejected or partial changes:
See ERN #26
_____________________________________________________________________________
Page: 7 Line: 171 Section: 2.16
Problem:
This is a comment against rdvk #10 from donn@interix.com.
The terminology used is consistent with that used in POSIX 1003.2.
Action:
Suggest no change, unless specific problems can be identified with
the terminology used by POSIX 1003.2.
_____________________________________________________________________________
editorial Enhancement Request Number 28
Frank Bug in XBD (rdvk# 110)
[prindle.xbd-6] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 7 Line: 177 Section: 2.18
Problem:
Missing hyphen between signal and safe.
Action:
Add the hyphen.
-------------------------------------------------------------------------------
_____________________________________________________________________________
comment Enhancement Request Number 29
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 53)
[DWC-XBD-11] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 11 Line: 247 Section: 2.39
Problem:
(need definition for special built-in)
This definition of Built-In Utility also defines the term "special built-in".
In other places in this draft where a definition defines multiple terms (and
the terms are not in alphabetic sequence), there is a separate definition for
the other terms that point back to the spot that actually defines the term.
In this case, "special built-in" is defined on P11, L247-248 in the definition
of "Built-In Utility (or Built-In)", but there is no explicit definition of
Special Built-In pointing back to this location.
Action:
Add the text:
2.xxx Special Built-In
See Section 2.39 on page 11.
with "xxx" replaced by the appropriate sequence number after P50, L1244.
Renumber following definitions.
_____________________________________________________________________________
Editorial Enhancement Request Number 30
schweikh@noc.dfn.de BUG in XBD (rdvk# 4)
[] Sun Jun 6, 12:25pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
change sentence to "An array of elements of type char".
_____________________________________________________________________________
Page: 12 Line: 281 Section: 2.44
Problem:
There's no such thing as a "array of type char". The C community
would say "An array of type char[]". (Or "array of char". The
type of an array can never be the element type.)
Action:
Change char to char[]
_____________________________________________________________________________
Objection Enhancement Request Number 31
donn@interix.com BUG in XBD (rdvk# 11)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Replace l 298 with
"A software or hardware object
that can be used to measure the apparent or actual passage of time."
_____________________________________________________________________________
Page: 12 Line: 298 Section: 2.51
Problem:
I'm not sure whether this is a tautology or an overbroad statement.
(That is, either it tells me nothing or too much.) (I don't see that
it eliminates a mechanical wall clock.)
Action:
"A software or hardware object usually consisting of one or more integers,
that can be used to measure the apparent or actual passage of time."
_____________________________________________________________________________
Comment Enhancement Request Number 32
schweikh@noc.dfn.de BUG in XBD (rdvk# 5)
[] Sun Jun 6, 12:25pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
The current text is inherited from existing POSIX.1 and is a "may be"
item.
_____________________________________________________________________________
Page: 13 Line: 301 Section: 2.52
Problem:
The text says "Clock ticks are one of the units that may be used to express
a value found in type clock_t."
Action:
But then, it may not. So this is as useful as stating that "The type
integer may store, among others, the value 42." This sentence should
be removed. It is content-free.
_____________________________________________________________________________
objection Enhancement Request Number 33
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 54)
[DWC-XBD-12] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 14 Line: 357 Section: 2.61
Problem:
(Composite Graphic Symbol)
We don't have a definition for the term "basic letter", but the use here
matches the definition of Base Character in section 2.28.
Action:
Change "basic letter" on P14, L357 to "base character".
_____________________________________________________________________________
Objection Enhancement Request Number 34
donn@interix.com BUG in XBD (rdvk# 12)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The editors will choose (whether rat or note)
_____________________________________________________________________________
Page: 15 Line: 375 Section: 2.64
Problem:
References to entities outside of the formal standards arena (such
as the Korn shell) need to be done as notes or rationale, not
apparently normative text.
Action:
Convert to Note or rationale (I don't care which).
_____________________________________________________________________________
Comment Enhancement Request Number 35
ajosey@opengroup.org Bug in XBD (rdvk# 31)
[TOG-XBD-004] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 16 Line: 390 Section: 2.68
Problem:
This is a comment against rdvk #13 from donn@interix.com.
I disagree. This use of "may" is consistent. Its optional
whether a system generate a core file upon abnormal process
termination.
Action:
Do nothing, leave this line unchanged.
_____________________________________________________________________________
Comment Enhancement Request Number 36
donn@interix.com BUG in XBD. (rdvk# 100)
[] Thu Jul 1, 10:13am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
See ERN #35
_____________________________________________________________________________
Page: 16 Line: 390 Section: 2.68
Problem:
It is unclear to me what the PURPOSE of that sentence is: if the
purpose is to grant permission to the implementation, then it's utterly
useless, because it's in a space where permission is already tacitly
granted. If the purpose is to notify the user that it could happen,
it's not granting permission, and "may" is reserved in this document for
that purpose. Define the purpose, and the action is clear.
Yes, I'm being pedantic, but we're NOT dealing with issues of "normal
English" here: we need to be sure that everything is unambiguous because
otherwise we get into interpretation requests. (Speaking of which,
interpretations for this document, given the set of participants, are
going to be a VERRRY interesting process.)
Action:
As stated previously.
_____________________________________________________________________________
Comment Enhancement Request Number 37
donn@interix.com BUG in XBD (rdvk# 13)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
see ERN #35
_____________________________________________________________________________
Page: 16 Line: 390 Section: 2.68
Problem:
I think this use of "may" is not consistent with the definition of "may".
Action:
Try "might"? There's no need to grant permission to implementations to
dump core, as it's already a permissable extension. Certainly it's nothing
under the direct control of the user.
_____________________________________________________________________________
Comment Enhancement Request Number 38
donn@interix.com BUG in XBD (rdvk# 14)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
"that can contain"
_____________________________________________________________________________
Page: 16 Line: 396 Section: 2.71
Problem:
I think this is granting permission (although that's more than needed)
to the user, not the implementation, so it should be "can".
Action:
may->can.
_____________________________________________________________________________
Comment Enhancement Request Number 39
donn@interix.com BUG in XBD. (rdvk# 101)
[] Thu Jul 1, 10:13am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_40 Reject_____
Rationale for rejected or partial changes:
dup of 40
_____________________________________________________________________________
Page: 16 Line: 402 Section: 2.74
Problem:
TOG-XBD-005 refers to an entry that I didn't submit, but I believe it
was the page/line/section above.
In any case, isn't "Change this text to:" obvious?
As far as changing the 1996 standard: the whole document is open for
discussion, so there's no formal problem with doing so. In this case
the definition is wrong, but it will have no effect on conformance of
implementations to fix it. (In fact, it may make some implementations
conformant, in case they DID implement direct I/O for a reason other
than performance!)
Action:
Change the text to read as suggested previously.
_____________________________________________________________________________
Comment Enhancement Request Number 40
donn@interix.com BUG in XBD (rdvk# 15)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The following text will be added in a reviewers note for the next
draft.
This is a possible replacement defn for the next draft, reviewers
should indicate which defn they prefer:
"An operation that does I/O in a way that is typically not otherwise
supported by the system, or which might circumvent the use of system
resources."
_____________________________________________________________________________
Page: 16 Line: 402 Section: 2.74
Problem:
So, if the purpose direct I/O is not to circumvent a system
performance optmization, but for some other purpose, it's not direct I/O?
Action:
"An operation that does I/O in a way that is typically not otherwise
supported by the system, or which might circumvent the use of system
resources. Such operations typically trade system performance for
individual application performance, predictability, or reliability."
_____________________________________________________________________________
Comment Enhancement Request Number 41
ajosey@opengroup.org Bug in XBD (rdvk# 32)
[TOG-XBD-005] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
See ERN 40
_____________________________________________________________________________
Page: 16 Line: 402 Section: 2.71
Problem:
This is a comment against rdvk #15 from donn@interix.com.
There is no action specified, just words in quotes. Is
this suggested replacement text?
Note if so, that this is replacement text for 2.2.2.27 from POSIX.1-1996
Action:
Donn needs to clarify what his action is.
_____________________________________________________________________________
Objection Enhancement Request Number 42
donn@interix.com BUG in XBD. (rdvk# 102)
[] Thu Jul 1, 10:13am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_16 Reject_____
Rationale for rejected or partial changes:
dup of 16
_____________________________________________________________________________
Page: 17 Line: 419 Section: 2.79
Problem:
ISO has some EXTREMELY strict rules about how inter-standard and intra-standard
references are to be made. Note that POSIX.1 says "this part of ISO/IEC
9945" for almost all self-references. That is the result of a 2 year
battle by Hal and Mary-Lynne to try to get something more reasonable past
ISO. It didn't happen. POSIX has a set of macros for "this document"
and various "that document" references, and my recommendation is that
those macros be used (and emit a recognizable sequence) so that when
the final form of document references is determined that the macro can
be changed. Unless major miracles happen, anything that reads decently
will be unacceptable in the long run.
Action:
Use the macros.
_____________________________________________________________________________
Objection Enhancement Request Number 43
donn@interix.com BUG in XBD (rdvk# 16)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_16 Reject_____
Rationale for rejected or partial changes:
dup of 16
_____________________________________________________________________________
Page: 17 Line: 419 Section: 2.79
Problem:
"XCU" needs to be converted to appropriate standardsese.
Action:
Use the appropriate POSIX "that standard" macro.
_____________________________________________________________________________
comment Enhancement Request Number 44
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 55)
[DWC-XBD-13] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 17 Line: 420-421 Section: 2.79
Problem:
(display)
The important point here is that utilities need not use file descriptors and
the write() function or printf() function to update the screen. There is no
need to talk about UNIX systems here.
Action:
Change "traditional UNIX system file descriptor" on P17, L420-421 to
"traditional file descriptor".
_____________________________________________________________________________
Comment Enhancement Request Number 45
ajosey@opengroup.org Bug in XBD (rdvk# 33)
[TOG-XBD-006] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_16 Reject_____
Rationale for rejected or partial changes:
dup of 16 (note line ref should have been 419)
_____________________________________________________________________________
Page: 17 Line: 491 Section: 2.79
Problem:
This is a comment against rdvk #16 from donn@interix.com.
The action is not clear. I'm not sure what the "appropriate"... is.
At the moment we refer to each physical book within the document
set as XSH, XCU and XBD respectively. Within a document we refer
to itself as "this document".
We should decide whether we want to continue to refer to the
books this way and what handle to use to refer to global requirements.
Action:
None proposed. However some discussion is needed.
_____________________________________________________________________________
Comment Enhancement Request Number 46
donn@interix.com BUG in XBD (rdvk# 17)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
(note to editor only on line 436)
_____________________________________________________________________________
Page: 18 Line: 436, Section: 2.81,
Problem:
Dot and dot-dot, as defined here, "dangle" bit as to what they're about.
Action:
Add "In the context of naming files...".
_____________________________________________________________________________
Comment Enhancement Request Number 47
Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 42)
[] Thu Jul 1, 4:07pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Replace line 444 by: "The conversion of an upper case character
that has a single-character lower case representation
into this lower case representation."
_____________________________________________________________________________
Page: 18 Line: 444 Section: 2.84
Problem:
Not all characters have a lower case form.
Some characters have several lower case forms, depending on context.
(Example: consider Greek Sigma.)
For a given character set, the lower case form corresponding to
a given upper case character may be locale dependent.
[I do not know where `Downshifting' is used in this draft standard,
but the area is messy and best avoided if possible.]
Action:
Replace line 444 by: "The conversion of an upper case character
that has a (unique) single-character lower case representation
(in the current locale) into this lower case representation."
_____________________________________________________________________________
comment Enhancement Request Number 48
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 56)
[DWC-XBD-14] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Delete P18, L445-448 and renumber following definitions.
_____________________________________________________________________________
Page: 18 Line: 445-448 Section: 2.85
Problem:
((Clock) Drift Rate)
The only reference I have been able to find in this document set (other than
the definition itself) to the terms "clock drift rate" and "drift rate" is one
use of "clock drift rate" in rationale for clock_getres() in XSH.
Action:
Delete P18, L445-448 and renumber following definitions.
If for some reason you decide that this definition must be kept, change
"(Clock) Drift Rate" on P18, L445 to "Clock Drift Rate"; change "positive
drift rate" on P18, L447 to "positive clock drift rate"; change "negative
drift rate" on P18, L447 to "negative clock drift rate"; move the definition
to follow P12, L300 to put it in correct sorted order; and renumber the
definitions as needed.
_____________________________________________________________________________
Comment Enhancement Request Number 49
donn@interix.com BUG in XBD (rdvk# 18)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
See ERN #50. Note that there are no interfaces for an
application to install drivers,
so a driver is part of the implementation
_____________________________________________________________________________
Page: 18 Line: 452 Section: 2.86
Problem:
More may/might/can. In this case, it should probably be...
Action:
"A driver might...".
_____________________________________________________________________________
Comment Enhancement Request Number 50
ajosey@opengroup.org Bug in XBD (rdvk# 34)
[TOG-XBD-007] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 18 Line: 452 Section: 2.86
Problem:
This is a comment against rdvk #18 from donn@interix.com.
Again I disagree with this may/might issue.
Action:
Leave text as is.
_____________________________________________________________________________
Comment Enhancement Request Number 51
donn@interix.com BUG in XBD. (rdvk# 103)
[] Thu Jul 1, 10:13am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_49 Reject_____
Rationale for rejected or partial changes:
dup of 49
_____________________________________________________________________________
Page: 18 Line: 452 Section: 2.86
Problem:
The same as the last may/can discussion: is this making an observation
or granting permission? Again it's useless to grant permission redundantly.
Action:
Use "might" (or move sentence to rationale, as it's an observation in
any case).
_____________________________________________________________________________
objection Enhancement Request Number 52
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 57)
[DWC-XBD-15] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
delete the last sentence on P19, L456-458
_____________________________________________________________________________
Page: 19 Line: 456-458 Section: 2.87
Problem:
(Effective Group ID)
If is dangerous to list THE set of functions that can access or change an
attribute in an evolving set of specifications. You have to be sure that the
definitions are updated when functions are added.
This definition says that the only ways to change the effective group ID of a
process is through the exec family of functions and the setgid() function.
The setregid() function can also be used to change the effective group ID.
Action:
Either delete the last sentence on P19, L456-458 or change "functions and
setgid()" on P19, L457-458 to "functions, setgid(), and setregid()". I prefer
the first choice.
_____________________________________________________________________________
objection Enhancement Request Number 53
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 58)
[DWC-XBD-16] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
delete the last sentence on P19, L461-462
_____________________________________________________________________________
Page: 19 Line: 461-462 Section: 2.88
Problem:
(Effective User ID)
See also my objection DWC-XBD-15.
This definition says that the only way to change the effective user ID of a
process is through exec and setuid(). The setreuid() function can also be
used to change the effective user ID.
Also, the reference to "exec" should be to "the exec family of functions", if
you keep this sentence.
Action:
Either delete the last sentence on P19, L461-462 or change "in exec and
setuid()" on P19, L462 to "in the exec family of functions, setreuid(), and
setuid()". I prefer the first choice.
_____________________________________________________________________________
editorial Enhancement Request Number 54
Frank Bug in XBD (rdvk# 111)
[prindle.xbd-7] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 19 Line: 473-475 Section: 2.93
Problem:
This section is out of alphabetical order.
Action:
Reverse this section with 2.94.
-------------------------------------------------------------------------------
_____________________________________________________________________________
objection Enhancement Request Number 55
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 59)
[DWC-XBD-17] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 20 Line: 496 Section: 2.99
Problem:
(Execute)
The definition of execute provided here only applies to its use in XCU; not in
XSH.
Action:
Change "To perform" on P20, L496 to "In the XCU specification, to perform".
_____________________________________________________________________________
objection Enhancement Request Number 56
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 60)
[DWC-XBD-18] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
. Delete P22, L533-534.
Change "permissions, to be returned by stat() or fstat()" on P22, L539
to "permissions.".
Add a period to the end of P22, L541.
_____________________________________________________________________________
Page: 22 Line: 533-534,539 Section: 2.109
Problem:
(File Access Permissions)
See also my objection DWC-XBD-15.
File access permissions can be changed by fchmod() as well as by chmod() and
they can be read by lstat() as well as by stat() and fstat().
The periods at the end of the first two bullet items on P22 are missing.
Action:
Perform one of the two following sets of actions:
1. Delete P22, L533-534.
Change "permissions, to be returned by stat() or fstat()" on P22, L539
to "permissions.".
Add a period to the end of P22, L541.
2. Change "chmod()" on P22, L534 to "chmod() and fchmod()".
Change "stat() or fstat()" on P22, L534 to "fstat(), lstat(), or
stat()".
Change "stat() or fstat()" on P22, L538 to "fstat(), lstat(), or
stat().".
Add a period to the end of P22, L541.
I prefer option 1.
_____________________________________________________________________________
objection Enhancement Request Number 57
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 61)
[DWC-XBD-19] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept___X_ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 25 Line: 623 Section: 2.123
Problem:
(File Times Update)
See also my objection DWC-XBD-15.
File time stamps need to be updated when lstat() is called as well as when
stat() and fstat() are called.
Action:
Change "stat() or fstat()" on P25, L623 to "fstat(), lstat(), or stat()".
_____________________________________________________________________________
Objection Enhancement Request Number 58
donn@interix.com BUG in XBD (rdvk# 19)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Replace the defn as follows:
"The current directory associated with the user database
(cxref to user database definition).
There is also an associated action on the editors to look at the
usage of HOME directory/home directory elsewhere
_____________________________________________________________________________
Page: 27 Line: 678 Section: 2.138
Problem:
Unless $HOME is set readonly, this is not true. cd (with no argument)
and cd ~ normally take the shell to wherever the current value of $HOME
is set.
Action:
"The directory named in $HOME, which is usually set to a default value
at login time, equal to the directory that the user starts in after
logging in."
_____________________________________________________________________________
Comment Enhancement Request Number 59
donn@interix.com BUG in XBD (rdvk# 20)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
There was consensus against making the change. It was felt it
added no value over the existing text.
_____________________________________________________________________________
Page: 29 Line: 730 Section: 2.152
Problem:
Vague in the presence of symbolic links.
Action:
"A synonym for 'hard link' or 'directory entry'. See...".
_____________________________________________________________________________
objection Enhancement Request Number 60
Frank Bug in XBD (rdvk# 119)
[prindle.xbd-15] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 30 Line: 748-751 Section: 2.159
Problem:
All references to "map" in XSH are with respect to a memory mapped file or
shared memory object. There is no useage of the term "map" to associate a
physical page to a virtual page, although of course the kernel and MMU are
doing this all the time. Nonetheless, there is no OS interface to explicitly
set up such a mapping. Once 1003.1j is approved, there will be a way to do
this, but it still will be via a memory object (typed memory object), so this
definition still need not mention physical memory.
Action:
Remove the phrases "a range of physical memory or", "physical memory or", and
"memory or".
-------------------------------------------------------------------------------
_____________________________________________________________________________
objection Enhancement Request Number 61
Frank Bug in XBD (rdvk# 112)
[prindle.xbd-8] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 31 Line: 757 Section: 2.161
Problem:
You are setting a precedent here, and also with all definitions which contain
text marked XSI. If you adhere to this precedent, then any definition text
that applies to an optional facility (optional in the POSIX sense, not the UNIX
sense) should be similarly marked. Also, note that alternative definitions may
apply when two different functionalities are referenced with the same name (e.g.
POSIX message queues and XSI message queues); in this case, each definition
should be marked with the appropriate code. The action section below lists all
definition text that I found that should be marked [see also prindle.xbd-11].
There may be some that I did not find.
Action:
Shade the following text and mark with the appropriate margin code:
page 7 line 166-167 section 2.14 Arm (a timer)
mark with TMR
page 7 line 173-174 section 2.17 Async-Cancel-Safe Function
mark with THR
page 7 line 179-182 section 2.19 Asynchronously Generated Signal
mark with THR
page 8 line 184-186 section 2.20 Asynchronous I/O Operation
mark with AIO
page 8 line 188-189 section 2.21 Asynchronous I/O Completion
mark with AIO
page 12 line 298-300 section 2.51 Clock
mark with TMR
page 14 line 359-361 section 2.62 Condition Variable
mark with THR
page 30 line 748-751 section 2.159 Map
mark with MF|SHM [see also prindle.xbd-15]
page 31 line 770-771 section 2.165 Message Queue
mark with MSG
page 31 line 770-771 section 2.165 Message Queue
add new definition for XSI style message queue and mark with XSI
page 32 line 783-786 section 2.169 Mutex
mark with THR
page 40 line 1005-1007 section 2.215 Priority
mark with PS|TPS
page 41 line 1014-1015 section 2.217 Priority-Based Scheduling
mark with PS|TPS
page 47 line 1147-1151 section 2.254 Scheduling Contention Scope
mark with TPS
page 48 line 1186-1187 section 2.259 Semaphore
mark with SEM
page 48 line 1186-1187 section 2.259 Semaphore
add new definition for XSI style semaphore and mark with XSI
page 48 line 1189-1191 section 2.260 Semaphore Lock Operation
mark with SEM
page 48 line 1189-1191 section 2.260 Semaphore Lock Operation
add new definition for XSI style semaphore lock operation and mark with XSI
page 48 line 1193-1195 section 2.261 Semaphore Unlock Operation
mark with SEM
page 48 line 1193-1195 section 2.261 Semaphore Unlock Operation
add new definition for XSI style semaphore unlock operation and mark with XSI
page 49 line 1207-1208 section 2.265 Shared Memory Object
mark with SHM|XSI [such objects do not exist outside these options]
page 53 line 1307-1308 section 2.293 Synchronized I/O Completion
mark with SIO
page 53 line 1311-1320 section 2.294 Synchronized I/O Data Integrity Completion
mark with SIO
page 54 line 1322-1324 section 2.295 Synchronized I/O File Integrity Completion
mark with SIO
page 54 line 1326-1327 section 2.296 Synchronized I/O Operation
mark with SIO
page 57 line 1418-1423 section 2.311 Thread
mark with THR
page 57 line 1425-1426 section 2.312 Thread ID
mark with THR
page 58 line 1428-1430 section 2.313 Thread List
mark with THR [see also prindle.xbd-14]
page 58 line 1432-1434 section 2.314 Thread-Safe
mark with THR
page 58 line 1436-1439 section 2.315 Thread-Specific Data Key
mark with THR
page 58 line 1443-1444 section 2.317 Timer
mark with TMR
page 58 line 1446-1447 section 2.318 Timer Overrun
mark with TMR
-------------------------------------------------------------------------------
_____________________________________________________________________________
Objection Enhancement Request Number 62
donn@interix.com BUG in XBD (rdvk# 21)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add to l 761 and 770 "In the context of programmatic message passing..."
Add to l 764 and 767 "In the context
of providing natural language messages to the user..."
_____________________________________________________________________________
Page: 31 Line: 761-768 Section: 2.162
Problem:
This is an unfortunate ordering of entries, because the two, mostly
unrelated, meanings of "message" are physically tangled together.
Action:
Add "In the context of programmatic message passing..." or "In the context
of providing natural language messages to the user..." to the appropriate
definitions.
_____________________________________________________________________________
objection Enhancement Request Number 63
Frank Bug in XBD (rdvk# 113)
[prindle.xbd-9] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The definition of the MAN margin code will be added as a reviewers
note to the codes section - note that the MAN margin code is an
interim code being used during document and will go away in the final
document.
_____________________________________________________________________________
Page: 34 Line: 843 Section: 2.184
Problem:
This is the first instance of the use of margin code MAN. It appears
extensively throughout XSH and XCU as well as XBD. It is not defined in the
codes or options sections of any of these documents.
Action:
Define the meaning of margin code MAN in the codes section of 1.3.
-------------------------------------------------------------------------------
_____________________________________________________________________________
Objection Enhancement Request Number 64
donn@interix.com BUG in XBD (rdvk# 22)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 37 Line: 907 Section: 2.199
Problem:
"although more than two leading slashes are..." is exactly the sort
of situation where "shall" is really needed. In the current text,
the more passive "are" seems to be more of an observation than a
requirement, but this is clearly a (somewhat counter-intuitive!)
requirement.
Action:
"are" -> "shall be".
_____________________________________________________________________________
Comment Enhancement Request Number 65
donn@interix.com BUG in XBD. (rdvk# 104)
[] Thu Jul 1, 10:13am -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_67 Reject_____
Rationale for rejected or partial changes:
dup of 67
_____________________________________________________________________________
Page: 37 Line: 908 Section: 2.199
Problem:
The issue of "//".
Action:
So moved, but since I probably won't be physically
present, I'd presume that the prior text had that effect. If not, what
is the mechanism for doing that?
_____________________________________________________________________________
Comment Enhancement Request Number 66
ajosey@opengroup.org Bug in XBD (rdvk# 35)
[TOG-XBD-008] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Accept the action (null)
_____________________________________________________________________________
Page: 37 Line: 908 Section: 2.199
Problem:
This is a comment against rdvk #23 from donn@interix.com.
This aardvark does not have an specific action to vote upon?
I think Donn should really propose a motion.
Action:
None.
_____________________________________________________________________________
Comment Enhancement Request Number 67
donn@interix.com BUG in XBD (rdvk# 23)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
This matter was discussed at length. The consensus of the reviewers
was that no change should be made.
_____________________________________________________________________________
Page: 37 Line: 908 Section: 2.199
Problem:
So the issue is brought up: should the // convetion be retained? Is there
any continuing constituency for it? A large fraction of the supposedly
portable Gnu software biffs this one, and no-one seems to notice, so
there isn't much need for it.
Action:
Vote, and delete or not. (Probably add rationale if retained.)
_____________________________________________________________________________
Editorial Enhancement Request Number 68
donn@interix.com BUG in XBD (rdvk# 24)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_46 Reject_____
Rationale for rejected or partial changes:
dup of 46
_____________________________________________________________________________
Page: 38 Line: 2.204 Section: 2.204
Problem:
Where does the dot operator in the shell fit into this? Does it belong
here, or with "dot", or ???
Action:
I can write text given a consensus as to what's wanted.
_____________________________________________________________________________
Comment Enhancement Request Number 69
ajosey@opengroup.org Bug in XBD (rdvk# 36)
[TOG-XBD-009] Thu Jul 1, 9:38am +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 38 Line: 951 Section: 2.204
Problem:
This is a comment against rdvk #24 from donn@interix.com.
I do not feel that it belongs here as this defines the term "Period"
not dot.
Action:
Do nothing.
_____________________________________________________________________________
objection Enhancement Request Number 70
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 62)
[DWC-XBD-20] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 39 Line: 967-975 Section: 2.208
Problem:
(Portable Character Set)
The way this definition is written along with Section 4.1 (Portable Character
Set) makes it look like there are two conflicting definitions for Portable
Character Set. After digging through both tables, it looks like the
definitions are compatible, but they are still confusing.
The reference to Table 4-1 on L974-975 should be a pointer to Section 2.209
(where portable filename character set is defined).
Action:
Change P39, L967-973 to:
conforming systems. See Section 4.1 on page 69.
Change "See Table 4-1 on page 69." on P39, L974-975 to "See Section 2.209 on
page 39.".
_____________________________________________________________________________
objection Enhancement Request Number 71
Frank Bug in XBD (rdvk# 114)
[prindle.xbd-10] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 41 Line: 1014-1015 Section: 2.217
Problem:
This definition should apply to processes as well as threads, as with Priority
on page 40. The problem also applies to:
page 47 line 1153-1165 section 2.255 Scheduling Policy.
Action:
Change "thread[s]" to "process[es] or thread[s]" throughout sections 2.217 and
2.255.
-------------------------------------------------------------------------------
_____________________________________________________________________________
objection Enhancement Request Number 72
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 63)
[DWC-XBD-21] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 42 Line: 1058-1059 Section: 2.226
Problem:
(Process List)
The term "Process List" is not defined in the definition of Thread List.
Also, there is no use of the term "process list" in this document set.
Action:
Delete P42, L1058-1059 and renumber the following definitions.
_____________________________________________________________________________
objection Enhancement Request Number 73
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 64)
[DWC-XBD-22] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below___X_ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Delete the last sentence on P44, L1089-1090
_____________________________________________________________________________
Page: 44 Line: 1089-1090 Section: 2.233
Problem:
(Real Group ID)
See also my objection DWC-XBD-15.
The real group ID can be changed by setregid() as well as by setgid().
Action:
Delete the last sentence on P44, L1089-1090 or change "setgid()" on P44, L1090
to "setgid() or setregid()".
I prefer the first choice.
_____________________________________________________________________________
objection Enhancement Request Number 74
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 65)
[DWC-XBD-23] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Delete the last sentence on P44, L1096-1097
_____________________________________________________________________________
Page: 44 Line: 1096-1097 Section: 2.235
Problem:
(Real User ID)
See also my objection DWC-XBD-15.
The real user ID can be changed by setreuid() as well as by setuid().
Action:
Delete the last sentence on P44, L1096-1097 or change "setuid()" on P44, L1097
to "setreuid() or setuid()".
I prefer the first choice.
_____________________________________________________________________________
objection Enhancement Request Number 75
Frank Bug in XBD (rdvk# 115)
[prindle.xbd-11] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_____ Accept as marked below___X_ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Use PS | TPS or PS TPS (be consistent with usage elsewhere for logical
OR notation on margin markers).
_____________________________________________________________________________
Page: 47 Line: 1153-1165 Section: 2.255
Problem:
Because there is a default scheduling policy in the absence of PS and TPS
options, the section need not be shaded or marked with margin codes. However,
the phrase "may modify the priorities" in two places should be marked PS and/or
TPS because nice() doesn't use the term priority.
Action:
Mark the phrase "may modify the priorities" as PS and/or TPS.
-------------------------------------------------------------------------------
_____________________________________________________________________________
objection Enhancement Request Number 76
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 66)
[DWC-XBD-24] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Make the proposed change in the action below and add a reviewers note
"Please check the calculations here. The last term of the current
expression adds in a day for every 4th year starting in 1973. (January 1st of
the each year following a leap year starting with the first leap year after
1970.) The first term above subtracts a day every 100 years starting in 2001.
The last term above adds a day back in every 400 years starting in 2001."
_____________________________________________________________________________
Page: 48 Line: 1183-1184 Section: 2.258
Problem:
(Seconds Since the Epoch)
The expression given for calculating seconds since the epoch on P48, L1183-
1184 has a couple of problems:
1. It doesn't account for leap seconds.
2. It doesn't account for the fact that the years 2100, 2200, and 2300 (as
well as three out of every 4 years that are a multiple of 100 after
2400) are not leap years.
I'm happy to ignore the first problem (as long as the definition clearly
states that leap seconds are not accounted for), but the other problem needs
to be corrected before this revision is approved.
When POSIX.1 was approved in 1990, this wasn't a serious problem. Almost all
hardware used a signed 32-bit time_t type, and that type of time_t expires
well before the year 2100. But, with some of the 64-bit operating systems
available today, the values stored in an object of type time_t are more
restricted by the fact that asctime() and related functions can't display a
date later than December 31, 9999 according to the C Standard than by the
limits of a 32-bit time_t.
Action:
Add the following to the end of the expression on P48, L1183-1184:
- ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
This definition does not account for leap seconds.
Please double check my calculations here. The last term of the current
expression adds in a day for every 4th year starting in 1973. (January 1st of
the each year following a leap year starting with the first leap year after
1970.) The first term above subtracts a day every 100 years starting in 2001.
The last term above adds a day back in every 400 years starting in 2001.
_____________________________________________________________________________
comment Enhancement Request Number 77
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 67)
[DWC-XBD-25] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add a reviewers note that this reference will be fixed when XNS5v2
is merged.
_____________________________________________________________________________
Page: 50 Line: 1233 Section: 2.273
Problem:
(Socket)
Referencing the Networking Services spec is fine in the Single UNIX
Specification. But, since it is not part of this document set, it isn't
appropriate here.
Action:
If sockets are moved into XSH in a later draft, change the reference to "the
Networking Services specification" on P50, L1233 to point to the appropriate
function in XSH.
Otherwise, delete "See the Networking Services specification." from P50, L1233
or delete this entire definition and renumber the following definitions.
_____________________________________________________________________________
comment Enhancement Request Number 78
Frank Bug in XBD (rdvk# 116)
[prindle.xbd-12] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_77 Reject_____
Rationale for rejected or partial changes:
dup of 77
_____________________________________________________________________________
Page: 50 Line: 1233 Section: 2.273
Problem:
The notation "the Networking Services specification" will need to be replaced
by "the XSH specification" (or it's revised name) in a later draft when XNS and
.1g are merged into this draft. Right now, all references to a socket reach a
dead end here because "the Networking Services specification" is undefined
(unless loosely interpreted as XNS Issue 5).
Action:
Remember to change this reference once XNS/POSIX.1g are merged into the
revision.
-------------------------------------------------------------------------------
_____________________________________________________________________________
Editorial Enhancement Request Number 79
donn@interix.com BUG in XBD (rdvk# 25)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 51 Line: 1266 Section: 2.282
Problem:
Well... maybe it's editorial. In any case, this is a particularly
unfortunate page break, with "stream" on one page and "STREAM" on the
next.
Action:
Add "See also STREAM, 2.283." here, and the converse in 2.283.
_____________________________________________________________________________
editorial Enhancement Request Number 80
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 68)
[DWC-XBD-26] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 55 Line: 1361 Section: 2.302
Problem:
(System Databases)
The word "that" is misspelled.
Action:
Change "tha" on P55, L1361 to "that".
_____________________________________________________________________________
comment Enhancement Request Number 81
Frank Bug in XBD (rdvk# 117)
[prindle.xbd-13] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
See the action item response below (note that some of this below
applies to XCU)
9907-06. Frank Prindle to check on use of "System Scheduling Priority" in
all volumes to see if the term can be replaced with "Nice Value". (ERN 81)
Issue:
Replacing all occurences of
"system scheduling priority"
with
"nice value".
*******************************************************************************
XSH - No changes required. "nice value" is used consistently throughout
*******************************************************************************
XBD - Section 2.305 changes:
Note that the original wording said:
A nice value of zero specifies the default policy of the system.
This is incorrect for two reasons (zero and policy) and should be:
The symbol NZERO specifies the default nice value of the system.
This change, and changing "system scheduling priority" to "nice value" is
reflected below. Note that this will have to be alphabetically re-sorted into
2.* because of its new name.
page 56 line 1369-1382 section Definitions: replace subsection with:
-------------------------------------------------------------------------------
2.xxx Nice Value
A number used as advise to the system to alter process scheduling priorities.
Raising the value should give a process additional preference when scheduling
a process to run. Lowering the value should reduce the preference and make a
process less likely to run. Typically, a process with higher nice value
runs to completion more quickly than an equivalent process with lower
nice value. The symbol NZERO specifies the default nice value of the system.
This definition is not intended to suggest that all processes in a system
have priorities that are comparable. Scheduling policy extensions such as
adding realtime priorities make the notion of a single underlying priority
for all scheduling policies problematic. Some systems may implement the
features related to nice to affect all processes on the system, others to
affect just the general time-sharing activities implied by this document set,
and others may have no effect at all. Because of the use of
``implementation-dependent'' in nice and renice, a wide range of
implementation strategies is possible.
-------------------------------------------------------------------------------
*******************************************************************************
XCU - page 592-595 section nice()
line 22183: change "system scheduling priority" to "nice value".
line 22188: same
line 22189: same
line 22191: same
line 22192: same
line 22193: same
line 22194: same
line 22201: same
line 22203: same
line 22205: same
line 22207: same
line 22208: same
line 22209: same
line 22263: same
line 22265: same
line 22272: same
line 22289: same
line 22290: change "priority" to "nice value".
line 22306: same
line 22307: same (twice on same line)
line 22311: same
line 22315: change "system scheduling priority" to "nice value".
line 22316-22321: leave the words "priorities" and "priority" here alone. In
this context, these are the proper words.
-------------------------------------------------------------------------------
XCU - page 666-668 section ps()
line 25122: change "system scheduling priority" to "nice value".
line 25221-25222: Either delete these two lines, or change "system scheduling
priority" to "nice value". The latter alternative makes only
a tiny bit of sense (i.e. an implementation could say:
"-o niceval" I suppose).
-------------------------------------------------------------------------------
XCU - page 675 section renice()
line 25438: change "system scheduling priorities" to "nice values".
line 25443: change "system scheduling priorities" to "nice values", and
change "system scheduling priority" to "nice value".
line 25448: change "system scheduling priority" to "nice value".
line 25449: same
line 25453: change "system scheduling priorities" to "nice values".
line 25465: change "system scheduling priority" to "nice value".
line 25467: same
line 25469: same
line 25470: same
line 25522: same
line 25523: change "scheduling priority" to "nice value".
line 25525: change "system scheduling priority" to "nice value".
line 25526: change "scheduling priority" to "nice value".
line 25528: change "system scheduling priority" to "nice value".
line 25529: change "scheduling priority" to "nice value".
line 25531: change "nice values" to "nice value increments" (this was in
error).
line 25532: delete "0 (the base scheduling priority)," (wrong and not useful).
line 25538-25542: replace with
-------------
Originally, this utility was written in the historical manner, using the term
``nice value''. This was always a point of concern with users because it was
never intuitively obvious what this meant. With a newer version of renice,
which used the term ``system scheduling priority'', it was hoped that novice
users could better understand what this utility was meant to do. Also, it would
be easier to document what the utility was meant to do. Unfortunately, the
addition of the POSIX realtime scheduling capabilities introduced the concepts
of process and thread scheduling priorities that were totally unaffected by the
nice/renice utilities or the nice()/setpriority() functions. Continuing to use
the term ``system scheduling priority'' would have incorrectly suggested that
these utilities and functions were indeed affecting these realtime priorities.
It was decided to revert to the historical term ``nice value'' to reference
this unrelated process attribute.
-------------
Also, the paragraph on page 595 line 22315-22321 section nice(), as fixed
by changes above, should be replicated here, either immediately before the
paragraph at line 25538 (my preference), or immediately after that paragraph.
-------------------------------------------------------------------------------
FINALLY: Note that my Acrobat Reader has a bug that keeps it from finding a
phrase that spans multiple lines. Though I think I've caught all of these, the
editors are strongly urged to do a search of the troff source for "system
scheduling priority" (even across lines) after applying the changes (if the
group accepts the changes) just to make sure I haven't missed any.
Sincerely,
Frank Prindle
prindle@voicenet.com
_____________________________________________________________________________
Page: 56 Line: 1369-1382 Section: 2.305
Problem:
This definition seems to relate to "nice value". But it appears to be
referenced nowhere, and thus seems superfluous. Perhaps it was
meant to set the stage for dealing with the issue of "nice value" vs.
"priority" in the strict sense, but this is unclear. This just seems to
introduce a meta-priority concept on top of "priority" and "nice value", which
should be kept separate and distinct. I am really unclear why this definition
exists.
Action:
Either use this defined term somewhere in XBD or XSH, or delete this definition.
-------------------------------------------------------------------------------
_____________________________________________________________________________
objection Enhancement Request Number 82
Frank Bug in XBD (rdvk# 118)
[prindle.xbd-14] Wed, 7 Jul 1999 19:26:27 -0500
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 58 Line: 1428-1430 Section: 2.313
Problem:
This definition diverges from POSIX (and is also WRONG). It uses "processes"
where "threads" was intended.
Action:
Replace "processes" by "threads" on each of these 3 lines.
-------------------------------------------------------------------------------
_____________________________________________________________________________
Comment Enhancement Request Number 83
Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 41)
[] Thu Jul 1, 4:07pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Replace line 1453 by: "The conversion of a lower case character
that has a single-character upper case representation
into this upper case representation."
_____________________________________________________________________________
Page: 59 Line: 1453 Section: 2.320
Problem:
Not all characters have an upper case form.
Some characters have several upper case forms, depending on context.
Sometimes the upper case representation of a single character
consists of two characters.
For a given character set, the upper case form corresponding to
a given lower case character may be locale dependent.
(Examples: consider German sharp s, Spanish ll, Dutch ij.
Turkish distinguishes `i' and `dotless i'
with capital forms `dotted I' and `I'. That is, in ISO 8859-9
the upper case form of SMALL LETTER i (06/09) is CAPITAL LETTER I
WITH DOT ABOVE (13/13) in a Turkish locale, but is CAPITAL LETTER I
(04/09) in most other locales.)
[I do not know where `Upshifting' is used in this draft standard,
but the area is messy and best avoided if possible.]
Action:
Replace line 1453 by: "The conversion of a lower case character
that has a (unique) single-character upper case representation
(in the current locale) into this upper case representation."
(Or, preferably: delete any mention of `Upshifting' from the entire standard.)
_____________________________________________________________________________
Comment Enhancement Request Number 84
Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 39)
[] Thu Jul 1, 4:07pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
See the definition of "executable file", it includes more than just object
files.
_____________________________________________________________________________
Page: 60 Line: 1478 Section: 2.324
Problem:
The definition of utility seems to exclude utilities written
in Java or utilities that are perl scripts, etc.
Action:
Delete in lines 1477-1479 the sentence "This program is ... the shell."
_____________________________________________________________________________
Comment Enhancement Request Number 85
Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 40)
[] Thu Jul 1, 4:07pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
change "a true" to "an"
_____________________________________________________________________________
Page: 60 Line: 1484 Section: 2.324
Problem:
The mention of performance characteristics and the word `only'
are inappropriate.
Action:
Replace in lines 1484-1487 the text ", but only ... true executable file."
by ". Such a function or built-in utility may differ from other utilities
in invocation behaviour: it need not be found using the command search order
described in the XCU specification, Section 3.9.2, Command Search and Execution."
_____________________________________________________________________________
Objection Enhancement Request Number 86
donn@interix.com BUG in XBD (rdvk# 26)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
1501-1504 -> rationale
_____________________________________________________________________________
Page: 60 Line: 1504 Section: 2.326
Problem:
As previously objected, Korn shell should be in rationale or a note.
Action:
Move to rationale or note (I don't care which).
_____________________________________________________________________________
objection Enhancement Request Number 87
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 69)
[DWC-XBD-27] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change "executes wait() or waitpid()" on P62, L1548-1549 to "waits for
it to terminate".
_____________________________________________________________________________
Page: 62 Line: 1548-1549 Section: 2.337
Problem:
(Zombie Process)
See also my objection DWC-XBD-15.
The waitid() function can also be used to wait for a child to terminate.
Action:
Choose one of the following:
1. Change "executes wait() or waitpid()" on P62, L1548-1549 to "waits for
it to terminate".
2. Change "wait() or" on P62, L1548 to "wait(), waitid(), or".
I prefer the first choice.
_____________________________________________________________________________
Comment Enhancement Request Number 88
Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 38)
[] Thu Jul 1, 4:07pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
"A process that has terminated and will be deleted when
its exit status has been reported to another process waiting for
that process to terminate."
_____________________________________________________________________________
Page: 62 Line: 1548 Section: 2.337
Problem:
The process doing the wait() need not be the zombie's parent.
(But it is the process that has the zombie's parent process ID as process ID.)
Action:
Write:
"A process that has terminated and will be deleted when
its exit status has been reported to a process executing
wait() or waitpid()."
_____________________________________________________________________________
Comment Enhancement Request Number 89
Andries.Brouwer@cwi.nl BUG in XBD (rdvk# 37)
[] Thu Jul 1, 4:07pm +0200
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
change 1555 to "when the representation allows the sign to be determined."
remove lines 1556-1557
_____________________________________________________________________________
Page: 62 Line: 1556 Section: 2.339
Problem:
The sentence is logically incorrect: a precision does not
have a representation.
The sentence is semantically incorrect: integer values
do not have distinct representations for +0 and -0
(in two's complement representation).
Action:
Write something like
"If the representation of the value of a variable has separate
sign and value parts (as is the case for the common representations
of floating point numbers), then the values +0 and -0 can be distinguished.
In some circumstances this is significant."
The parenthetical part can also be omitted.
_____________________________________________________________________________
editorial Enhancement Request Number 90
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 70)
[DWC-XBD-28] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 66 Line: 1626 Section: 3
Problem:
(File Format Notation)
A closing parenthesis in the description of field width has been moved from
where it appeared in POSIX.2 to make the parenthetical element contain more
text than it contained in POSIX.2. POSIX.2 did it correctly.
Action:
Change "been given to the field width)." on P66, L1626 to "been given) to the
field width.".
_____________________________________________________________________________
objection Enhancement Request Number 91
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 71)
[DWC-XBD-29] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 67 Line: 1672-1674 Section: 3
Problem:
(File Format Notation)
The example on P67, L1669-1676 doesn't make sense. In POSIX.2, this example
shows that the File Format Notation:
"%d\n",
could be implemented using a printf() function call:
printf("%6d\n", foo);
By dropping the "6" from the printf() call, the difference between File Format
Notation and printf() format strings is lost.
Action:
Change '"%d\n"' on P67, L1674 to '"%6d\n"'.
_____________________________________________________________________________
objection Enhancement Request Number 92
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 72)
[DWC-XBD-30] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 68 Line: 1695 Section: 3
Problem:
(File Format Notation)
The description of the g and G File Format Notation conversion characters has
been changed from the description in POSIX.2. The description in POSIX.2 says
that the g and G conversion characters use style f, e, or E and then describes
when e is used (meaning that f is used in all other cases). Here, you say
that "style g is used only if the exponent" meets certain requirements. This
seems to shift the decision on whether to use e, E, or f from the
implementation to the application being required to check the value of an
entity being printed before using the g and G File Format Notation conversion
characters.
Action:
Change "style g" on P68, L1695 to "style e (or E)".
_____________________________________________________________________________
Objection Enhancement Request Number 93
donn@interix.com BUG in XBD (rdvk# 27)
[] Tue Jun 29, 5:00pm -0600
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_94 Reject_____
Rationale for rejected or partial changes:
dup of 94
_____________________________________________________________________________
Page: 70 Line: 1787 Section: 4.1
Problem:
What is the goal of requiring that the characters in the portable
character set be positive? This would appear to require that an
EBCDIC-based system treat char type as unsigned, regardless of any
other justification for treating char type as signed.
Action:
Justify or remove.
_____________________________________________________________________________
Objection Enhancement Request Number 94
Jeffrey bug in XBD (rdvk# 122)
[Copeland-xbd-1] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__
Rationale for rejected or partial changes:
The review group consensus was that this draws an incorrect conclusion.
The text has been here since XPG4
and vendors supporting EBCDIC have not see a problem here.
_____________________________________________________________________________
Page: 70 Line: 1788-1789 Section: 4.1
Problem:
This phrasing restricts us to character sets which represent the portable
characters in 7 bits on machines with signed chars, and thus (for example)
prevents EBCDIC from being used as a character set.
Action:
Remove the sentence "Moveover, if the value is stores in an object of
C-language type char, it is guaranteed to be positive..."
_____________________________________________________________________________
editorial Enhancement Request Number 95
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 73)
[DWC-XBD-31] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 71 Line: 1830 Section: 4.3
Problem:
(C Language Wide-Character Codes)
The parenthetical element after "wide-character strings (see Section 4.3)"
points to itself. It should point to the definition of wide-character
strings.
Action:
Change "(see Section 4.3)" on P71, L1830 to "(see Section 2.231 on page 61)".
_____________________________________________________________________________
Comment Enhancement Request Number 96
Jeffrey bug in XBD (rdvk# 123)
[Copeland-xbd-2] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change "portable set" to "portable character set."
_____________________________________________________________________________
Page: 72 Line: 1863 Section: 4.4
Problem:
We're talking about converting between subsets of charmaps, and are using
the same term used to describe the characters in table 4-1, when what we
actually mean is the portable filename character set. (On the other hand,
it's possible this paragraph is more tangled than I think, in which case the
sentences on line 1860-1865 really need to be re-written to be clear.)
Action:
Change "portable set" to "portable filename character set."
_____________________________________________________________________________
Comment Enhancement Request Number 97
Jeffrey bug in XBD (rdvk# 124)
[Copeland-xbd-3] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___
Rationale for rejected or partial changes:
The consensus of the review group is that applications make use of this
feature and we do not want to break them.
_____________________________________________________________________________
Page: 72 Line: 1894-1900 Section: 4.4
Problem:
Settable escape and comment characters in charmap files, while they represent
existing practice, are neither necessary nor desirable for portability or
readability. Implementations are made simpler by the removal of this feature.
They should be deprecated.
Action:
Mark these paragraphs as deprecated, to be withdrawn.
_____________________________________________________________________________
Comment Enhancement Request Number 98
Jeffrey bug in XBD (rdvk# 125)
[Copeland-xbd-4] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change "followed by an integer formed by one or more decimal digits."
to "followed by an integer formed by one or more decimal digits. Both
integers must contain the same number of digits."
_____________________________________________________________________________
Page: 73 Line: 1918-1919 Section: 4.4
Problem:
It's implied that the number of digits in the pair of symbolic names like
" ... " can be different. It is foolishness for them to
not be the same, since it can be confusing to both machine and human
parsers what the actual sequence of character codes is.
Action:
Change "followed by an integer formed by one or more decimal digits."
to "followed by an integer formed by one or more decimal digits. Both
integers must contain the same number of digits." [Alternately, explicitly
allow the number of digits to be different, but add a note in the rationale
explaining the danger of this course of action.]
_____________________________________________________________________________
Comment Enhancement Request Number 99
Jeffrey bug in XBD (rdvk# 126)
[Copeland-xbd-5] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
the text "big endian" will be removed
_____________________________________________________________________________
Page: 73 Line: 1948 Section: 4.4
Problem:
The term "big endian" is never defined.
Action:
Add a definition to chapter 2, like:
"Big endian: a numeric representation for numbers of greater than one octet
where the octets are presented in decreasing order of significance, that
is, the most significant octet is presented first, and the least significant
octet is presented last."
_____________________________________________________________________________
Editorial Enhancement Request Number 100
Jeffrey bug in XBD (rdvk# 127)
[Copeland-xbd-6] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
delete the words "by the application"
_____________________________________________________________________________
Page: 75 Line: 1981 Section: 5.1
Problem:
What "application" are we talking about?
Action:
Change "the application" to "by the local system administrator or other
authorized user".
_____________________________________________________________________________
Comment Enhancement Request Number 101
Jeffrey bug in XBD (rdvk# 128)
[Copeland-xbd-7] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change line 1984 "even if the ability to create locales, all
implementation ...." , also unshade as this is a POSIX requirement
_____________________________________________________________________________
Page: 75 Line: 1982 Section: 5.1
Problem:
This is at variance with the description of localedef in XCU. This
phrasing suggests that support of localedef is optional; XCU now requires
it on page 489, line 18155. Which is the intended requirement?
Action:
Either change "see the XCU specification" to "it is required by the XCU
specification." Or remove the corresponding XSI-extension sentence in XCU.
_____________________________________________________________________________
Comment Enhancement Request Number 102
Jeffrey bug in XBD (rdvk# 129)
[Copeland-xbd-8] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject___X_
Rationale for rejected or partial changes:
The environment variable is not the operand described on the localedef
manual page.
_____________________________________________________________________________
Page: 75 Line: 1990 Section: 5.1
Problem:
The description "environment variable begins with a slash" is at variance
with the description in the XCU description of the localedef utility, which
says (page 490, line 18196) "contains one or more slash characters". Which
is it, begins or contains? The less restrictive version is better, since
it allows something like LANG=foo/ rather than LANG="$(pwd)/foo/"
Action:
Change the words "begins with a slash" to "contains one or more slash
characters" in XBD.
_____________________________________________________________________________
Comment Enhancement Request Number 103
Jeffrey bug in XBD (rdvk# 130)
[Copeland-xbd-9] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___
Rationale for rejected or partial changes:
Reject for the same reason as ERN 97
_____________________________________________________________________________
Page: 77 Line: 2050-2059 Section: 5.3
Problem:
Settable escape and comment characters in localedef files, while they
represent existing practice, are neither necessary nor desirable for
portability or readability. Implementations are made simpler by the removal
of this feature. They should be deprecated.
Action:
Mark these paragraphs as deprecated, to be withdrawn.
_____________________________________________________________________________
Comment Enhancement Request Number 104
Jeffrey bug in XBD (rdvk# 131)
[Copeland-xbd-10] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___
Rationale for rejected or partial changes:
The consensus of the review group is that the text is this way
intentionally, and that it should be left.
_____________________________________________________________________________
Page: 78 Line: 2085-2092 Section: 5.3
Problem:
This paragraph is a portability minefield. By using characters outside the
portable character set in localedef files, they are no longer portable.
Action:
Change the opening sentences of the paragraph to "A character can be
represented by the character itself, if the character is from the portable
character set. Using other characters as themselves is deprecated." Also,
remove the eszet from the example on line 2092.
_____________________________________________________________________________
Editorial Enhancement Request Number 105
Jeffrey bug in XBD (rdvk# 132)
[Copeland-xbd-11] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 80 Line: 2175-2176 Section: 5.3.1
Problem:
Surely we mean want to use the portable names for the character, ""
instead of "space".
Action:
Change "space, form-feed, newline, ..." to ", ,
, ..."
Also at
page 80 line 2178 section 5.3.1 Editorial
page 80 line 2190 section 5.3.1 Editorial
page 80 line 2198 section 5.3.1 Editorial
page 81 line 2203 section 5.3.1 Editorial
page 81 line 2219 section 5.3.1 Editorial
page 83 line 2286 section 5.3.1 Editorial
_____________________________________________________________________________
Editorial Enhancement Request Number 106
Jeffrey bug in XBD (rdvk# 133)
[Copeland-xbd-12] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change "the limit {COLL_WEIGHTS_MAX}" to "the limit {COLL_WEIGHTS_MAX} as
specified in as defined in ." (where
is the appropriate reference).
_____________________________________________________________________________
Page: 87 Line: 2497 Section: 5.3.2
Problem:
No reference for {COLL_WEIGHTS_MAX}.
Action:
Change "the limit {COLL_WEIGHTS_MAX}" to "the limit {COLL_WEIGHTS_MAX} as
specified in ."
_____________________________________________________________________________
Editorial Enhancement Request Number 107
Jeffrey bug in XBD (rdvk# 134)
[Copeland-xbd-13] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 89 Line: 2589 Section: 5.3.2
Problem:
Missing close angle bracket
Action:
Change ", ..."
_____________________________________________________________________________
Comment Enhancement Request Number 108
Jeffrey bug in XBD (rdvk# 135)
[Copeland-xbd-14] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add a reviewers note that we expect the following sentence to
change when .2b is merged .
_____________________________________________________________________________
Page: 89 Line: 2594 Section: 5.3.2
Problem:
Incomplete explanation.
Action:
After "The NUL character compares lower than any other character." add
"even if NUL is explicitly defined elsewhere in the collating order."
_____________________________________________________________________________
editorial Enhancement Request Number 109
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 74)
[DWC-XBD-32] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 89 Line: 2598 Section: 5.3.2
Problem:
(LC_COLLATE--Collation Order)
There is an extraneous space.
Action:
Change "< collating-symbol>" on P89, L2598 to "".
_____________________________________________________________________________
Editorial Enhancement Request Number 110
Jeffrey bug in XBD (rdvk# 136)
[Copeland-xbd-15] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 91 Line: 2663 Section: 5.3.2
Problem:
tabs don't line up
Action:
Add some extra space before ";" to make the columns line up
_____________________________________________________________________________
editorial Enhancement Request Number 111
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 75)
[DWC-XBD-33] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 97 Line: 2985 Section: 5.3.4
Problem:
(LC_NUMERIC)
The text "the strings only can contain integers" is awkward English.
Action:
Change "only can" on P97, L2985 to "can only".
_____________________________________________________________________________
comment Enhancement Request Number 112
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 76)
[DWC-XBD-34] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add a reviewers note in the text that:
XBD, D1 , ERN 112 raised the following question:
(replicate problem/action statement)
Reviewers are asked to state their opinion.
_____________________________________________________________________________
Page: 98 Line: 3027 Section: 5.3.4
Problem:
(LC_NUMERIC)
I don't understand why P98, L3019 says that grouping in the POSIX locale is
"-1", but the grouping line in the POSIX Locale Value column of the table on
P98, L3023-3027 contains "N/A".
Action:
Change "N/A" on P98, L3027 to "-1".
_____________________________________________________________________________
Editorial Enhancement Request Number 113
Jeffrey bug in XBD (rdvk# 137)
[Copeland-xbd-16] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Accept that these should be MAN shading for
page 102 line 3164 section 5.3.5
page 102 line 3169-3173 section 5.3.5
_____________________________________________________________________________
Page: 100 Line: 3116-3118 Section: 5.3.5
Problem:
Missing shading on part of an extension.
Action:
Add shading to these lines.
Also at
page 102 line 3164 section 5.3.5
page 102 line 3169-3173 section 5.3.5
_____________________________________________________________________________
comment Enhancement Request Number 114
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 77)
[DWC-XBD-35] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 105 Line: 3337 Section: 5.3.6
Problem:
(LC_MESSAGES)
The note saying that yesstr and nostr values have changed from the values they
had in XBD3 is not appropriate in this Austin-Group document in normative
text.
Action:
Move P105, L3337 to follow P106, L3365.
_____________________________________________________________________________
Comment Enhancement Request Number 115
Jeffrey bug in XBD (rdvk# 138)
[Copeland-xbd-17] Wed, 14 Jul 1999 13:54:58 -0600 (MDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_114 Reject_____
Rationale for rejected or partial changes:
dup of 114
_____________________________________________________________________________
Page: 105 Line: 3337 Section: 5.3.6
Problem:
We use the legacy "yesstr" and "nostr" in the examples and the table on the
following page, but don't specify the operands here.
Action:
Add the operands back into this description. In XBD5, the phrasing was:
yesstr (LEGACY) The operand consists of a fixed string (not a regular
expression) that can be used by an application for composition of a message
that lists and acceptable affirmative reponse, such as in a prompt.
nostr (LEGACY) The operand consists of a fixed string that can be used by
an application for composition of a message that lists an acceptable
negative response.
_____________________________________________________________________________
objection Enhancement Request Number 116
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 78)
[DWC-XBD-36] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 106 Line: 3364 Section: 5.3.6
Problem:
(LC_MESSAGES--LC_MESSAGES Application Usage)
See also my comment DWC-XBD-8.
I didn't find a reference to the Internationalization Guide in the referenced
documents list. There is an Internationalisation Guide that was part of XPG2,
but it doesn't seem reasonable to be referencing that from XBD6.
Action:
Delete "(see the Internationalization Guide) " from P106, L3364.
_____________________________________________________________________________
objection Enhancement Request Number 117
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 79)
[DWC-XBD-37] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 108-114 Line: 3427-3640 Section: 5.4.2
Problem:
(Locale Grammar)
There are lots of extraneous spaces in the grammar presented on pages 108-114.
While some of these are strictly editorial and won't make any difference in
the meaning of the grammar, others have spaces in quotes that completely
change the meaning of the grammar being described.
Action:
Change "lc_ctype | lc_collate" on P108, L3427 to "lc_ctype | lc_collate".
Change "CHAR | CHARSYMBOL" on P108, L3434 to "CHAR | CHARSYMBOL".
Change "'upper' | 'lower'" on P109, L3466 to "'upper' | 'lower'".
Change "' ;'" on P109, L3471 to "';'".
Change "' ;'" on P109, L3472 to "';'".
Change "' ;'" on P109, L3478 to "';'".
If at all possible, force P110, L3501-3502 to fit on a single line. If that
isn't possible, at least force the "'from' on P110, L3502 to be indented more
than it currently is.
Change "' ;'" on P110, L3509 to "';'".
Change "' ;'" on P111, L3529 to "';'".
Change "' ;'" on P111, L3530 to "';'".
Change "'int_curr_symbol' | 'currency_symbol'" on P112, L3575 to
"'int_curr_symbol' | 'currency_symbol'".
Change "'int_frac_digits' | 'frac_digits'" on P112, L3582 to
"'int_frac_digits' | 'frac_digits'".
Change "mon_keyword_grouping :" on P112, L3587 to "mon_keyword_grouping :".
Change "' ;'" on P112, L3590 to "';'".
Change "' ;'" on P113, L3615 to "';'".
Change "' ;'" on P114, L3640 to "';'".
_____________________________________________________________________________
objection Enhancement Request Number 118
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 80)
[DWC-XBD-38] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 115 Line: 3673 Section: 5.5
Problem:
(Locale Definition Example)
See also my objection DWC-XBD-36.
I didn't find a reference to the Internationalization Guide in the referenced
documents list. There is an Internationalisation Guide that was part of XPG2,
but it doesn't seem reasonable to be referencing that from XBD6.
Action:
Delete P115, L3673.
_____________________________________________________________________________
editorial Enhancement Request Number 119
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 81)
[DWC-XBD-39] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
A reviewers note will be added to ask the question in the next draft
_____________________________________________________________________________
Page: 115 Line: 3685 Section: 5.5
Problem:
(Locale Definition Example)
Most proposed standards that I've seen don't include a date of adoption
designator. Is Canadian standard Z243.4.1-1990 a "proposed" standard, or is
(or was) it an "approved" standard?
Action:
If Z243.4.1 is (or was) an approved standard, delete " proposed" from P115,
L3685.
If the standard has been revised, consider updating this text to refer to the
revision.
_____________________________________________________________________________
comment Enhancement Request Number 120
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 82)
[DWC-XBD-40] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add a reviewers note in the text that:
XBD, D1 , ERN 120 raised the following problem statement:
{replicate problem/proposed action}
Reviewers are asked to state their preference.
_____________________________________________________________________________
Page: 117 Line: 3765-3772 Section: 5.5
Problem:
(Locale Definition Example)
I know this text comes directly from POSIX.2 rationale, but this example
inside the example is not clear. The "", "", and "" used
in this example are not defined in the preceding text. There is no indication
of how this encoding would be done or why "" is included at the end of
either encoding.
Action:
Replace P117, L3765-3772 with the following text:
# As an example, the strings "Bach" and "bach" would be compared as follows:
# In the first pass, both strings would be evaluated as .
# In the second pass, both strings would be evaluated as
# .
# In the third pass, "Bach" would sort after "bach" because "Bach" would
# be evaluated as while "bach" would
# be evaluated as (and
# comes before in the set of collating symbols defined above).
_____________________________________________________________________________
comment Enhancement Request Number 121
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 83)
[DWC-XBD-41] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 122 Line: 3959 Section: 6.2
Problem:
(Internationalization Variables)
The environment variables LANG and NLS_PATH do not start with "LC_". Adding
"LC_*" in parentheses in this list makes it confusing.
Action:
Change "The environment variables (LC_*), LANG, LC_ALL" on P122, L3959 to "The
environment variables LANG, LC_ALL".
_____________________________________________________________________________
editorial Enhancement Request Number 122
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 84)
[DWC-XBD-42] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The editor will fix the layout appropriately
_____________________________________________________________________________
Page: 131 Line: 4266,4267,4271 Section: 7.3.3
Problem:
(BRE Special Characters)
There are some missing periods at the ends of sentences here.
Action:
Add a period to the end of P131, L4266.
Add a period to the end of P131, L4267.
Add a period to the end of P131, L4271.
_____________________________________________________________________________
objection Enhancement Request Number 123
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 85)
[DWC-XBD-43] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 132 Line: 4318 Section: 7.3.5
Problem:
(RE Bracket Expression)
The discussion on collating symbols in RE bracket expressions says to see the
symbol in an example in Collation Order on page 89, but is not
defined on that page or in that section.
Action:
Change "Collation Order on page 89" on P132, L4318 to "The collating-symbol
Keyword on page 88".
_____________________________________________________________________________
comment Enhancement Request Number 124
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 86)
[DWC-XBD-44] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 133 Line: 4359 Section: 7.3.5
Problem:
(RE Bracket Expression)
One-to-many mappings are discussed in section 5.3.2 on page 87. LC_COLLATE is
mentioned in the introduction to locales in section 5.1 on page 75, but there
is no mention of one-to-many mappings until 12 pages later.
Action:
Change "(see the description of LC_COLLATE in Chapter 5 on page 75)" on P133,
L4358-4359 to "(see the description of LC_COLLATE in Section 5.3.2 on page
87)".
_____________________________________________________________________________
objection Enhancement Request Number 125
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 87)
[DWC-XBD-45] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
This will be fixed to fit all on a single line
_____________________________________________________________________________
Page: 134 Line: 4395-4396 Section: 7.3.6
Problem:
(BREs Matching Multiple Characters)
The example showing a valid BRE with ten subexpressions in this draft on P134,
L4395-4396 fit on a single (although long) line on POSIX.2, volume 2, P802,
L2094 and fit on a single line in XBD5 on P107. When the line was split in
this draft a " \c" was added to show that the RE was continued on the next
line. But, "\c" in a BRE yields undefined results. (See P131, L4254-4257.)
This is an example of a BRE, not an example of a command language that
recognizes "\c" as a continuation sequence. If for some reason this BRE can't
be presented on a single line in this document, shorten the BRE until it fits.
Action:
Drop " \c " from P134, L4395-4396. If the resulting string won't
fit on a single line, make changes as follows until it does fit on a single
line:
1. Drop the point size of the text,
2. change one or more of the subexpressions that contain two letters to
only contain a single letter (e.g. change "ab" to "a"),
3. drop the interval expression, and/or
4. drop one or more of the asterisks.
I greatly prefer the first option in the list and I prefer the second option
over the last two options.
_____________________________________________________________________________
comment Enhancement Request Number 126
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 88)
[DWC-XBD-46] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The editor will fix the layout appropriately
_____________________________________________________________________________
Page: 136 Line: 4471,4472,4478 Section: 7.4.3
Problem:
(ERE Special Characters)
Three sentences in bullet lists in this section are missing terminating
periods.
The reference to "interval expression" on P136, L4472 should give a pointer to
where the term is defined.
Action:
Add a period to the end of P136, L4471.
Add " (see Section 7.5.6 on page 137)." to the end of P136, L4472.
Add a period to the end of P136, L4478.
_____________________________________________________________________________
editorial Enhancement Request Number 127
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 89)
[DWC-XBD-47] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 141 Line: 4664 Section: 7.5.2
Problem:
(RE and Bracket Expression Grammar)
There are some extra spaces in this grammar. Although this is strictly
editorial and won't make any difference in the meaning of the grammar, the
extra spaces are distracting.
Action:
Change "matching_list ']'" on P141, L4664 to "matching_list ']'".
_____________________________________________________________________________
editorial Enhancement Request Number 128
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 90)
[DWC-XBD-48] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The editor will fix the layout appropriately
_____________________________________________________________________________
Page: 143 Line: 4743,4744,4745,4747 Section: 7.5.3
Problem:
(ERE Grammar)
See also my editorial comment DWC-XBD-2.
There are several sentences in this section missing terminating periods.
Action:
Add a period to the end of P143, L4743.
Add a period to the end of P143, L4744.
Add a period to the end of P143, L4745.
Add a period to the end of P143, L4747.
_____________________________________________________________________________
objection Enhancement Request Number 129
nick@usenix.org Bug in XBD (rdvk# 3)
{3} Sat Jun 5, 12:39am +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add to the end of line 4753 - "unless otherwise specified below".
_____________________________________________________________________________
Page: 145 Line: 4753 Section: 8.1
Problem:
The requirement on line 4753 conflicts with line 4758.
Action:
Add to the end of line 4743 - "unless otherwise specified below".
_____________________________________________________________________________
objection Enhancement Request Number 130
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 91)
[DWC-XBD-49] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 146 Line: 4790 Section: 8.2
Problem:
(Output Devices and Terminal Types)
None of the control characters shown in Table 8-1 are listed in Section 4.1;
most are listed in section 5.3.1. Even there, however, , , ,
, , , and are not listed. You need to add an additional
column to Table 8-1 with the heading "Symbolic Name" as listed below to show
the correspondence between control character names in this table and symbolic
names in the cntrl keyword of LC_CTYPE on page 83.
Action:
Change "Section 4.1 on page 69" on P146, L4790" to "Section 5.3.1 on page 83".
Add an additional column to Table 8-1 with the heading "Symbolic Name"
duplicating the corresponding entries except for the differences below:
Value Symbolic Name
========== ====================
All others Same in both columns
to indicate the relationships between control character values and control
character symbolic names.
_____________________________________________________________________________
objection Enhancement Request Number 131
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 92)
[DWC-XBD-50] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 147 Line: 4840 Section: 9.1.2
Problem:
(General Terminal Interface: Process Groups)
The meaning of this sentence has been completely reversed. In POSIX.1-1996,
P183, L30-32, the corresponding sentence is:
When there is no longer any process whose process ID or process group ID
matches the process group ID of the foreground process group, the
terminal shall have no foreground process group.
In XBD5, P119, the corresponding sentence is:
When there is no longer any process whose process ID or process group ID
matches the process group ID of the foreground process group, the
terminal will have no foreground process group.
In this draft, the "shall have no" and "will have no" has been changed to
"has". The current sentence in this draft is not even correct English. The
missing "no" is extremely important here.
Action:
Change "the terminal has foreground" on P147, L4840 to "the terminal will have
no foreground" or to "the terminal shall have no foreground".
_____________________________________________________________________________
editorial Enhancement Request Number 132
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 93)
[DWC-XBD-51] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 149 Line: 4905 Section: 9.1.5
Problem:
(General Terminal Interface: Input Processing and Reading Data)
There is no fcntrl() function in this document set.
Action:
Change "fcntrl()" on P149, L4905 to "fcntl()".
_____________________________________________________________________________
editorial Enhancement Request Number 133
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 94)
[DWC-XBD-52] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 149 Line: 4939 Section: 9.1.7
Problem:
(General Terminal Interface: Non-Canonical Mode Input Processing)
ISO POSIX-1 refers to the 1996 version of the standard. This should be
talking about the revision we're creating.
Action:
Change "The ISO POSIX-1 standard" on P149, L4939 to "This document set".
_____________________________________________________________________________
editorial Enhancement Request Number 134
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 95)
[DWC-XBD-53] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept__X__ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 151 Line: 5028-5029 Section: 9.1.9
Problem:
(General Terminal Interface: Special Characters)
I thought all of the FIPS mandated features in POSIX.1-1996 were supposed to
be mandated without markings in this revision.
Action:
Drop the FIPS marking and the shading on P151, L5028-5029.
_____________________________________________________________________________
editorial Enhancement Request Number 135
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 96)
[DWC-XBD-54] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Change "-f" with "f" in bold font on P161, L5348 to put "f" in courier font.
Change all occurrences of "-a", "-b", and "-c" with "a", "b", and "c" in bold
font on P162, L5361-5364 to put "a", "b", and "c" in courier font.
Change "-C, -l, and -1" with "C", "l", and "1" in bold font on P163, L5422 to
put "C", "l", and "1" in courier font.
_____________________________________________________________________________
Page: 161-163 Line: 5331,5337,5346,5348,5361-5364,5422 Section: 10.1
Problem:
(Utility Argument Syntax)
There are several font problems with option letters in this section. They
frequently appear in italic or bold font when they should appear in a courier
font.
Action:
Change "[-d|-e] [-f" with "d|", "e", and "f" in italic font on P161, L5331 to
put "d", "e", and "f" in courier font and put "|" in a non-italic font.
Change "-c" with "c" in bold font on P161, L5337 to put "c" in courier font.
Change "-c" with "c" in bold font on P161, L5346 to put "c" in courier font.
Change "-f" with "f" in bold font on P161, L5348 to put "f" in courier font.
Change all occurrences of "-a", "-b", and "-c" with "a", "b", and "c" in bold
font on P162, L5361-5364 to put "a", "b", and "c" in courier font.
Change "-C, -l, and -1" with "C", "l", and "1" in bold font on P163, L5422 to
put "C", "l", and "1" in courier font.
_____________________________________________________________________________
objection Enhancement Request Number 136
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 98)
[DWC-XBD-56] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The editors will do their best, due to timescales this may be
deferred to a later draft, if so we'll retain this item as ongoing.
We probably need someone to identify all terms to be indexed and
markup a draft.
_____________________________________________________________________________
Page: 167-171 Line: 0 Section: Index
Problem:
(Index)
There are several problems in the index:
1. There is an inconsistent use of fonts on the page numbers. (Ideally,
the place where a term is defined should be in bold font, and the rest
should be in Roman font.)
2. All uses of defined terms must be indexed. (This is crucial when trying
to find all places where a term is used while trying to implement a
conforming system.)
3. The index shouldn't be creating classifications of terms that are not
defined in the normative text. (For example, none of the codes defined
on page 3 are split into classifications where they are defined, but
some are split into the classifications "extension" [see P168, L84-86]
and "warning" [see P171, L225-229] in the index.)
4. Some defined terms do not appear in the index at all. (For example,
+/-0 is defined in section 2.339. But, it does not appear in the index
at all.)
Action:
Fix the index to address the problems noted above.
_____________________________________________________________________________
editorial Enhancement Request Number 137
Don.Cragun@eng.sun.com Bug in XBD (rdvk# 97)
[DWC-XBD-55] Thu, 1 Jul 1999 07:38:22 -0700 (PDT)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 163 Line: 5417 Section: 10.1
Problem:
(Utility Argument Syntax)
There is an extraneous space.
Action:
Change "SYNOPSIS ." on P163, L5417 to "SYNOPSIS.".
_____________________________________________________________________________
Objection Enhancement Request Number 138
donn@interix.com BUG in XBD (rdvk# 120)
[] Tue, 13 Jul 1999 13:59:42 -0600
_____________________________________________________________________________
Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
The review group agrees with the sentiment however notes that the action
is not specific. The review group notes that this is being done
and would ask all reviewers to highlight any missing rationale in
the next draft.
_____________________________________________________________________________
Page: 185 Line: 5531 Section: 10.2
Problem:
The rationale for this whole section (possibly this whole
document, I haven't checked) was not brought forward from
the corresponding .2 text. Since this particular piece
of rationale contains a particularly important statement,
that of forever reserving -W to implementors, I find this
a particularly serious omission.
Action:
Bring forward to this document all the original .1 and .2
rationale that has been deleted (with the appropriate application
of editorial license for formatting and dealing with resolved
issues.)
(See P809 line 2384 of the current .2.)