XRAT D3R Aardvark Reports Austin-396 Page 1 of 1
Submitted by Andrew Josey, The Open Group. Sep 10, 2007
Aardvark Summary Table
______________________
ERN 1 Accept
ERN 2 Accept
ERN 3 Accept
ERN 4 Accept as marked
ERN 5 Accept
ERN 6 Accept
ERN 7 Accept as marked
ERN 8 Duplicate of XSH ERN 30
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 1
gwc:xxxxxxxxxxxxx Bug in XRATd3 A.1.1 (rdvk# 1)
[gwc known as POSIX.1] Wed, 18 Jul 2007 16:02:24 +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3313 Line: 112244 Section: A.1.1
Problem:
The change in the name the standard calls itself has resulted in the
following statement in the XRAT introduction:
"POSIX.1-200x is known as POSIX.1"
Action:
Change
"The family of standards extends to many topics; POSIX.1-200x is
known as POSIX.1 and consists of both operating system interfaces
and shell and utilities."
to
"The family of standards extends to many topics; POSIX.1 consists
of both operating system interfaces and shell and utilities."
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 2
nick:xxxxxxxxxx Bug in XRATd3 Portability (rdvk# 4)
{nms-opt-01} Fri, 6 Jul 2007 22:19:41 +0100 (BST)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3318 Line: 112465 Section: Portability
Problem:
The example given on lines 112465-112467 is obsolete, in that the THR
option no longer exists:
For example, if functionality is marked with THR in the margin, it will
be available on all systems supporting the Threads option, but may not
be available on some others.
Action:
Change the example to use one of the margin codes that is still in
effect. I have chosen RPP here, but any valid margin code could be
used.
Change lines 112465-112467 to:
For example, if functionality is marked with RPP in the margin, it will
be available on all systems supporting the Robust Mutex Priority
Protection option, but may not be available on some others.
_____________________________________________________________________________
COMMENT Enhancement Request Number 3
gwc:xxxxxxxxxxxxx Bug in XRATd3 A.3 Symbolic Link (rdvk# 5)
[gwc symlink def] Tue, 10 Jul 2007 12:18:12 +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3337 Line: 113258 Section: A.3
Problem:
The rationale associated with the "symbolic link" definition needs
to be updated to account for the planned change to mandate inodes for
symbolic links, and with other changes related to symbolic links
that have already been made since the 2004 edition of the standard.
There is also a problem with the statement in the third paragraph:
"a trailing slash is considered to be the final component of
a pathname"
The term "pathname component" is defined to be a synonym for
"filename", and a filename cannot contain a slash, therefore a
trailing slash cannot be a "component of a pathname" (i.e. pathname
component).
Action:
Replace the first five paragraphs under "Symbolic Link" (lines
113258-113292) with the following:
"Earlier versions of this standard did not require symbolic links
to have attributes such as ownership and a file serial number.
This was because the 4.4 BSD implementation did not have them,
and it was expected that other implementations may wish to do the
same. However, experience with 4.4 BSD has shown that symbolic
links implemented in this way cause problems for users and
application writers, and later BSD systems have reverted to using
inodes to implement symbolic links. Allowing no-inode symbolic
links also caused problems in the standard. For example, leaving
the st_ino value for symbolic links unspecified meant that the
common technique of comparing the st_dev and st_ino values for two
pathnames to see if they refer to the same file could only be used
with stat() in conforming applications and not with lstat().
The standard now requires symbolic links to have meaningful values
for the same struct stat fields as regular files, except for the
file mode bits in st_mode. Historically the file mode bits were
unused (the contents of a symbolic link could always be read), but
implementations differed as to whether the file mode bits (as
returned in st_mode or reported by ls -l) were set according to
the umask or just to a fixed value such as 0777. Accordingly the
standard requires the file mode bits to be ignored by readlink()
and when a symbolic link is followed during pathname resolution,
but leaves the corresponding part of the value returned in st_mode
unspecified.
Historical implementations were followed when determining which
interfaces should apply to symbolic links. Interfaces that
historically followed symbolic links include chmod(), stat() and
utime(). Interfaces that historically did not follow symbolic
links include lstat(), rename(), remove(), rmdir(), and unlink().
For chown() and link() historical implementations differed.
POSIX.1-200x inherited the lchown() function from the Single
UNIX Specification version 2, and therefore requires chown() to
follow symbolic links. Earlier versions of this standard
required link() to follow symbolic links, but with the addition
of the linkat() function (which has a flag to indicate whether
to follow symbolic links) both behaviors are now allowed for
link().
When the final component of a pathname is a symbolic link, the
standard requires that a trailing slash causes the link to be
followed. This is the behavior of historical implementations.
For example, for /a/b and /a/b/, if /a/b is a symbolic link to a
directory, then /a/b refers to the symbolic link, and /a/b/ refers
to the directory to which the symbolic link points."
Replace the second paragraph under "Third Domain" (lines
113344-113351) with:
"The intention of the Shell and Utilities volume of POSIX.1-200x
is that the operation that the utility is performing is applied
to the symbolic link itself, if that operation is applicable to
symbolic links. If the operation is not applicable to symbolic
links, the symbolic link should be ignored. Specifically, by
default, no change should be made to the file referenced by the
symbolic link."
At line 113389 delete:
"The only standard utilities that require the -P option are cd
and pwd; see the note below."
At line 113413 delete:
"Earlier versions of this standard did not require the pwd utility
to be a built-in utility. Now that pwd is required to set an
environment variable in the current shell execution environment,
it must be a built-in utility."
At line 113419 change:
"Symbolic links in 4.4 BSD do not have"
to:
"Symbolic links in 4.4 BSD did not have"
_____________________________________________________________________________
COMMENT Enhancement Request Number 4
nick:xxxxxxxxxx Bug in XRATd3 Seconds since the epoch (rdvk# 2)
{nms-leapsecond-01} Fri, 6 Jul 2007 22:38:24 +0100 (BST)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
change from
As of September 2000, 24 leap seconds had been added to UTC since the
Epoch, 1 January, 1970. Historically, one leap second is added every
15 months on average, so this offset can be expected to grow steadily
with time.
to
As of December 2007, 23 leap seconds had been added to UTC since the
Epoch, 1 January, 1970. Historically, one leap second is added every 15
months on average, so this offset can be expected to grow with
time.
_____________________________________________________________________________
Page: 3352 Line: 113842 Section: Seconds
Problem:
The statement made on line 113842-113844 has always been wrong.
As of September 2000, 24 leap seconds had been added to UTC since the
Epoch, 1 January, 1970. Historically, one leap second is added every
15 months on average, so this offset can be expected to grow steadily
with time.
According to NIST, at this point (i.e. today), 23 leap seconds have
been added. In September 2000, only 22 had been added.
>From NIST:
The first leap second was inserted into the UTC time scale on June 30,
1972. Leap seconds are used to keep the difference between UT1 and
UTC to within 0.9 s. The table below lists all leap seconds that have
already occurred, or are scheduled to occur.
All leap seconds listed in the table are positive leap seconds, which
means an extra second is inserted into the UTC time scale. The sequence
of events is:
23h 59m 59s - 23h 59m 60s - 00h 00m 00s
NOTE: No leap second will be added at the end of December 2007
Leap Seconds Inserted into the UTC Time Scale
Date MJD
2005-12-31 53735
1998-12-31 51178
1997-06-30 50629
1995-12-31 50082
1994-06-30 49533
1993-06-30 49168
1992-06-30 48803
1990-12-31 48256
1989-12-31 47891
1987-12-31 47160
1985-06-30 46246
1983-06-30 45515
1982-06-30 45150
1981-06-30 44785
1979-12-31 44238
1978-12-31 43873
1977-12-31 43508
1976-12-31 43143
1975-12-31 42777
1974-12-31 42412
1973-12-31 42047
1972-12-31 41682
1972-06-30 41498
(source http://tf.nist.gov/pubs/bulletin/leapsecond.htm)
Action:
While not critical (and out of scope) I would like to see the sentence
amended to read:
As of December 2007, 23 leap seconds had been added to UTC since the
Epoch, 1 January, 1970. Historically, one leap second is added every 15
months on average, so this offset can be expected to grow steadily with
time.
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 5
ebb9:xxxxxxx Bug in XRATd3 B.1.1 (rdvk# 6)
{ebb.history} Mon, 23 Jul 2007 21:56:30 +0100 (BST)
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3394 Line: 115461 Section: B.1.1
Problem:
The list of new functions in Issue 7 omits open_wmemstream.
Action:
In sorted order in the table at line 115441, add open_wmemstream().
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 6
gwc:xxxxxxxxxxxxx Bug in XRATd3 B.1.1 (rdvk# 3)
[gwc utime OB] Fri, 6 Jul 2007 09:48:10 +0100
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3396 Line: 115543 Section: B.1.1
Problem:
Since utime() is a base function, not XSI, it should be in the
list of obsolescent base functions.
Action:
Move utime() from the 2nd table on the page to the 1st table.
_____________________________________________________________________________
COMMENT Enhancement Request Number 7
ieeeballoter:xxxxxxxx IEEE ballot comments on Draft 3 (rdvk# 8)
[IEEE] 06/15/2007
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
Add a new section B.3.2 System Interfaces removed from the Previous Revision
The following system interfaces, headers, and external variables
were removed in the previous revision of this standard:
advance( ), brk( ), chroot( ), compile( ), cuserid( ), gamma( ),
getdtablesize( ), getpagesize( ), getpass( ),
getw( ), putw( ), re_comp( ), re_exec( ), regcmp( ), regex( ), sbrk( ),
sigstack( ), step( ), ttyslot( ),
valloc( ), wait3( ), , , , loc1, _ _loc1,
loc2, locs 1
Make Exclusion of Utilities in C.4 to become C.4.3
Add a new section C.4.1 Utilities removed from this Revision
None.
Add a new section C.4.2 Utilities removed from the Previous Revision
The following utilities were removed in the previous revision
of this standard:
calendar, cancel, cc, col, cpio, cu, dircmp, dis, egrep, fgrep, line, lint,
lpstat, mail, pack, pcat, pg, spell,
sum, tar, unpack, uulog, uuname, uupick, uuto
_____________________________________________________________________________
Page: 3520 Line: 0 Section: B.3.1
Problem:
Date: 06/15/2007
Must be satisfied: No
Category: Technical
Page: 3520
Sub-clause: B.3.1
Comment: Replying to your resolution detail "would welcome detailed
wording instructions" from my comment (comment #10 in previous ballot):
I have no access to all P1003.1 versions, so I cannot provide such
wording. But I propose to simply include B.3.1 from all previous version
of P1003.1 standard.
Action:
See Problem
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 8
Michael T Kerrisk BUG in XRAT (rdvk# 7)
Tue, 24 Jul 2007 10:35:54 +0200
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_XSH_ERN_30 Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3609 Line: 124279 Section: E.1
Problem:
Line 124279 mentions the function futimesat(), but this function has
been renamed utimesnsat() (see XSH line 31880).
Action:
At page 3609 line 124279:
Change: "futimesat()"
to "utimesnsat()"
All line numbers refer to draft 3 of the specification.