From ajosey@rdg.opengroup.org Thu Apr 17 10:07:43 1997 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id KAA26082 for ; Thu, 17 Apr 1997 10:07:41 +0200 Received: by mailgate.rdg.opengroup.org; id AA25346; Thu, 17 Apr 1997 09:07:52 GMT Message-Id: <9704170907.AA25346@mailgate.rdg.opengroup.org> Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA01602; Thu, 17 Apr 1997 09:04:45 +0100 From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Thu, 17 Apr 1997 09:04:45 +0100 In-Reply-To: JimIsaak's message as of May 29, 9:56am. Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sc22wg15@dkuug.dk Subject: 1003.1-1990 Finalised PASC Interps Attached are the finalised PASC 1003.1-1990 interpretations since October 1996. These are being circulated in accordance with Action 9610-60 . regards Andrew ----- Andrew Josey PASC Functional Chair Interpretations The Open Group Apex Plaza,Forbury Road, Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 Email: a.josey@opengroup.org #--------------------------------CUT HERE------------------------------------- #! /bin/sh # # This is a shell archive. Save this into a file, edit it # and delete all lines above this comment. Then give this # file to sh by executing the command "sh file". The files # will be extracted into the current directory owned by # you with default permissions. # # The files contained herein are: # # -rw-r--r-- 1 ajosey other 3026 Feb 23 09:35 pasc-1003.1-76.html # -rw-r--r-- 1 ajosey other 3363 Feb 23 09:35 pasc-1003.1-77.html # -rw-r--r-- 1 ajosey other 2346 Feb 23 09:35 pasc-1003.1-78.html # echo 'x - pasc-1003.1-76.html' if test -f pasc-1003.1-76.html; then echo 'shar: not overwriting pasc-1003.1-76.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1-76.html X X X[Ref: pasc-1003.1-76] Topic: read() X X X

XPASC Interpretation Ref: pasc-1003.1-76
Topic: read() X

X

X

XThis is an unapproved interpretation of PASC P1003.1-1990. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 23 February,1997 X

X
X								1003.1-90  #76
X
X _____________________________________________________________________________
X
X	Interpretation Number:	76
X	Topic: 			read()
X	Relevant Sections:	 6.4.1.2
X
XInterpretation Request:
X-----------------------
X
X	Date: Fri, 15 Mar 1996 19:09:29 -0700
X	From: baford@snake.cs.utah.edu (Bryan Ford)
X
X
XI would like a clarification on section 6.4.1 in IEEE Std 1003.1-1990,
Xthe System Interface Standard, describing the read() function.
X
XIn the description in section 6.4.1.2, it is unclear exactly in what
Xstate the caller's read buffer is left after the function returns,
Xin two specific situations:
X
X1. If the read() function returns a value less than "nbyte" but greater
Xthan or equal to zero, indicating that the end-of-file was reached,
Xmust POSIX implementations guarantee that the remaining bytes in the
Xbuffer, from just after the last valid byte transferred to "nbyte"-1,
Xbe left unmodified by the read() function?  Or is the remainder of the
Xbuffer left with undefined contents?
X
X2. Similarly, if the read() function returns an error other than EINTR,
Xmust POSIX implementations guarantee that the caller's read buffer
Xis left unmodified, or are the contents undefined?  (It seems fairly clear
Xfrom paragraph 7 that at least for EINTR the contents must be considered
Xundefined, since the OS may return -1 anyway after data has been transferred.)
X
XIn the (unlikely I would think) case that this issue hasn't already been
Xdealt with and resolved, my suggested correction would be to state explicitly
Xthat after a partial read, the contents of the remainder of the buffer
Xis undefined, and after an error, the contents of the entire read buffer
Xis undefined.  In systems that implement read() using some IPC mechanism
Xthat may have alignment or size granularity restrictions, it is much more
Xdifficult (and in some cases impossible) to implement read() by receiving
Xdata from the IPC system directly into the caller's buffer without copying it,
Xif the implementation must guarantee that no more bytes in the read buffer
Xare modified than are actually successfully transferred.
X
XInterpretation response
X------------------------
XFor both of these issues, the standard does not speak to this issue, 
Xand as such no conformance distinction can be made between alternative	
Ximplementations based on this. This is being referred to the 
Xsponsor.
X
XRationale
X-------------
XOnce the buffer has been passed to the system, the state of
Xthe buffer is undefined.
X
XForwarded to Interpretations group: Apr 10 1996
XForwarded for review: Oct 22 1996
XFinalised: Nov 24 1996
X
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1-76.html` -ne 82; then echo 'shar: pasc-1003.1-76.html was damaged during transit (should have been 82 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1-77.html' if test -f pasc-1003.1-77.html; then echo 'shar: not overwriting pasc-1003.1-77.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1-77.html X X X[Ref: pasc-1003.1-77] Topic: rename X X X

XPASC Interpretation Ref: pasc-1003.1-77
Topic: rename X

X

X

XThis is an unapproved interpretation of PASC P1003.1-1990. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 23 February,1997 X

X
X								1003.1-90  #77
X
X _____________________________________________________________________________
X
X	Interpretation Number:	77
X	Topic:               rename
X	Relevant Sections:   5.5.3.2.
X
XInterpretation Request:
X-----------------------
X
X
X	Date: Wed, 4 Sep 1996 15:58:08 -0400 (EDT)
X	From: "Kirk Russell" <kirk@qnx.com>
X
X(Note line numbers are against 1003.1b-1993, but this is applicable
Xto 1003.1-90 included in ISO POSIX.1-1996)
X
XThe standard states:
X
X		If the old argument and the new argument both refer
X		to links to the same existing file, the rename()
X		function shall return successfully and perform no
X		other action.
X
X
XQuestion:
X
X	I am assuming that the rationale for the above clause was to ensure
X	that rename("x", "x") does not remove the file "x".  I based my
X	assumption on the rationale in subsection B.5.5.3 (lines 3625 through
X	3628).  I feel that the above clause is too restrictive.
X
X	If you have two files "x" and "y" that both refer to links to the
X	same existing file, then rename("x", "y") will return successfully
X	and perform no other action.  I think if would be more logical to
X	perform a remove of link "x" in this situation.
X
X	This implementation of rename() would result in the following
X	behaviour from the shell prompt (assuming the mv utility is
X	compliant with IEEE Std 1003.2-1992 4.43.2 lines 7095 to 7103):
X
X		$ touch x 
X		$ ln x y 
X		$ ls -li x y 
X		186625 -rw-r--r--  2 kirk  techies  0 Aug 23 10:43 x 
X		186625 -rw-r--r--  2 kirk  techies  0 Aug 23 10:43 y 
X		$ mv x y 
X		$ ls -li y 
X		186625 -rw-r--r--  1 kirk  techies  0 Aug 23 10:43 y 
X
X
X	But this implementation may fail some PCTS, since the test suite
X	may look at only "inode numbers" to determine if the "x" and "y"
X	are links to the same existing file and therefore would expect no
X	action to be performed.
X
X	The "4.4BSD Lite" distribution appears to support this
X	implementation.  Since rename() was first implemented in 4.xBSD,
X	I found it strange that the 4.4BSD implementation of rename()
X	would not pass a PCTS. I used the following files a reference:
X
X		/usr/src/sys/ufs/ufs/ufs_vnops.c
X		/usr/src/sys/kern/vfs_syscalls.c
X
X
XSuggested Correction:
X
X	The clause should be changed to:
X
X		If the old argument and the new argument both refer to
X		a file with the same name in the same directory, the
X		rename() function shall return successfully and perform
X		no other action.
X
X
X
XInterpretation response
X------------------------
XThe standard clearly states the requirements for rename(), and conforming 
Ximplementations must conform to this.
X
X
XRationale
X-------------
XInterpretations must be a comment on what
Xthe standard actually does say, not what it should say, nor 
Xwhat it says incorrectly. Changes to the standard may be submitted
Xthrough the revisions process.
X
XForwarded to Interpretations group: Sep 8 1996
XForwarded for review: Oct 22 1996
XFinalised: Nov 24 1996
X
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1-77.html` -ne 114; then echo 'shar: pasc-1003.1-77.html was damaged during transit (should have been 114 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.1-78.html' if test -f pasc-1003.1-78.html; then echo 'shar: not overwriting pasc-1003.1-78.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.1-78.html X X X[Ref: pasc-1003.1-78] Topic: opendir() error return value X X X

XPASC Interpretation Ref: pasc-1003.1-78
Topic: opendir() error return value X

X

X

XThis is an unapproved interpretation of PASC P1003.1-1990. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 23 February,1997 X

X
X								1003.1-90  #78
X
X _____________________________________________________________________________
X
X	Interpretation Number:	78
X	Topic:               opendir() error return value
X	Relevant Sections:   5.1.2.4
X
XInterpretation Request:
X-----------------------
X
X	Date: Mon, 9 Sep 1996 15:10:13 -0400 (EDT)
X	From: "Kirk Russell" <kirk@qnx.com>
X
X		Standard:1003.1-1996 (second edition 1996-07-12)
X		SubSection:5.1.2.4 (line 118)
X
X		function shall return -1 and set errno to the corresponding
X		value
X
X
XQuestion:
X
X	The following sources document the return value as NULL:
X		1003.1-1996 subsection 5.1.2.3		line 94
X		1003.1b-1993 subsection 5.1.2.3		line 74
X		1003.1b-1993 subsection 5.1.2.4		line 96
X		2003.1-1992 subsection 5.1.2.2.4	line 253
X
X	Does line 118 of std 1003.1-1996 subsection 5.1.2.4 indicate
X	a new contradiction or a typographical error?
X
XSuggested Correction:
X
X	The clause should be changed to:
X
X		function shall return NULL and set errno to the corresponding
X		value
X
X
X
XInterpretation response
X------------------------
XThis is a typographical error. The published IEEE Std 1003.1-1996
Xis inconsistent with IEEE Std 1003.1-1990 and IEEE Std 1003.1b-1993.
X
XClauses 5.1.2.4 ll 102 & 114  should be changed to say:
X		function shall return NULL and set errno to the corresponding
X		value
X
XIt is recommended that this be fixed by applying the IEEE erratta process.
X
XRationale
X-------------
XThe approved IEEE Std 1003.1-1990  does not include
Xthis wording. IEEE Std 1003.1-1996 is a re-publication
Xof 1003.1-1990 merged together with the amendments. Since
Xthere are intended to be no substantive changes apart
Xfrom the merging of the amendments, this would appear to be
Xa problem introduced with the merge.
X
XForwarded to Interpretations group: Sep 17 1996
XReview start: Oct 22 1996
XFinalised: Nov 24 1996
X
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.1-78.html` -ne 85; then echo 'shar: pasc-1003.1-78.html was damaged during transit (should have been 85 bytes)' fi fi ; : end of overwriting check exit 0