Document Number: AUSTIN/125 Title: XBD/ft/3 Aardvark Change Request Report Revision Date: 2002-08-02 Source: Andrew Josey, Chair Action: for review This report contains the draft dispositions of the aardvark comments submitted against the XBD/ft/3 (3rd batch of FT aardvark) text. Aardvark Summary Table ______________________ ERN 1 Accept as marked ERN 2 Accept as marked ERN 3 Accept ERN 4 Accept _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 tjr@FreeBSD.ORG Defect in XBD Locale (rdvk# 4) {1} Tue, 23 Jul 2002 04:34:56 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Agree with Paul Eggert, without adding this text we do not specify how comparisons are being done. Insert after XCU page 957 in correct alphabetical order LC_COLLATE Determine the locale for ordering rules. Add to the Change History The LC_COLLATE environment variable is added _____________________________________________________________________________ Page: 132 Line: 4426 Section: Locale Problem: Defect code : 1. Error XBD Page 132 Line 4426 (in D7) states LC_COLLATE affects the execution of uniq. XCU Page 3159 Line 36800 does not list LC_COLLATE as affecting the execution of the uniq utility. Action: 1. Remove uniq from the list of utilities mentioned on XBD line 4426. or 2. Add a description of how LC_COLLATE affects the uniq utility between XCU lines 36807 and 36808. [Ed recommendation: This looks like a TC1 candidate, although we need to determine what the fix is From Paul Eggert: (2) is the correct action to take; otherwise, "sort -u" and "sort | uniq" would disagree if the input contains two lines that compare equal with strcoll but not-equal with strcmp. I mentioned this problem in PASC Interpretation reference 1003.2 #217, but my guess is that the request never got handled due to the press of 1003.1-2001 work. Here is a proposed action to implement (2). Insert after XCU page 956 line 36754: Comparisons of lines shall be performed using the collating sequence of the current locale. Insert after XCU page 957 line 36798: LC_COLLATE Determine the locale for ordering rules. Jon Hitchcock replied: I believe that this change will adversely affect existing applications that process data for which the default collating sequence is not appropriate. For example, I once worked on an application that displayed a list of printer types. Originally, it naively used "sort -u" to sort the list and remove duplicates. This worked fine until a user ran it on an operating system with a default collating sequence which ignored plus signs, so that "hp_jet" and "hp_jet+" were treated as equal and only one was displayed. We chose to fix the application by replacing "sort -u" with "sort | uniq". Note that "sort | uniq" does not guarantee to remove duplicate lines if there is another line that collates equally (the application usage at XCU line 36826 is misleading). But that guarantee was not necessary for our application. I suggest adopting (1), or adding a new option to uniq to explicitly select the use of LC_COLLATE.] _____________________________________________________________________________ COMMENT Enhancement Request Number 2 bjh21@netbsd.org Defect in XBD (rdvk# 2) {bjh21:sigaction} Wed, 26 Jun 2002 18:32:06 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (1) At line 10810, replace "What to do on receipt of signal" with "SIG_DFL or SIG_IGN". (2) At line 10815-10816, replace "Pointer to signal handler function or one of the macros SIG_IGN or SIG_DFL" with "Signal-catching function" (*CROSS VOLUME CHANGE*) (3) In XSH6 on page 1338 line 41433 change the Description entry in the table to "SIG_DFL or SIG_IGN". _____________________________________________________________________________ Page: 303 Line: 10810-10816 Section: Problem: The text claims that the sa_sigaction member of struct sigaction can have the values SIG_DFL or SIG_IGN. At XSH page 1338 line 41432-41439 section sigaction(), on the other hand, these aren't mentioned as possible values for sa_sigaction, but are mentioned as possible values for sa_handler. I believe that the specification under sigaction() is correct, though it's notable that the use of SIG_DFL and SIG_IGN isn't documented in sigaction() at all. Action: (1) At line 10810, replace "What to do on receipt of signal" with "SIG_DFL, SIG_IGN, or pointer to a function". (2) At line 10815-10816, replace "Pointer to signal handler function or one of the macros SIG_IGN or SIG_DFL" with "Signal-catching function" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 bjh21@netbsd.org Defect in XBD (rdvk# 1) {bjh21:sa_sigaction decl} Wed, 26 Jun 2002 18:32:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 303 Line: 10814 Section: Problem: The declaration given for the sa_sigaction member of struct sigaction is not syntactically valid. Action: Replace: void (*)(int, siginfo_t *, void *) sa_sigaction with: void (*sa_sigaction)(int, siginfo_t *, void *) _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 wollman@lcs.mit.edu Defect in XBD unistd.h (rdvk# 3) {GAW-2002f} Mon, 15 Jul 2002 23:38:15 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 405 Line: 14322-14333 Section: unistd.h Problem: Defect code : 1. Error XCUft @ p. 215, ll. 8371-8377 (the c99 command) says that the V6_LP64_OFF64 programming environment has 32-bit integers. The referenced XBD text says that it has 64-bit integers. Action: As commonly used, ``LP64'' refers to the environment described in XCU and not the one described in XBD. Change the XBD text to read ``32-bit int, and 64-bit long, pointer, and off_t''. [Ed recommendation: TC1 candidate]