PASC Interpretation Ref: pasc-1003.1-76
Topic: read()

Use of the information contained in this unapproved document is at your own risk.

Last update: 23 February,1997

								1003.1-90  #76

 _____________________________________________________________________________

	Interpretation Number:	76
	Topic: 			read()
	Relevant Sections:	 6.4.1.2

Interpretation Request:
-----------------------

	Date: Fri, 15 Mar 1996 19:09:29 -0700
	From: baford@snake.cs.utah.edu (Bryan Ford)


I would like a clarification on section 6.4.1 in IEEE Std 1003.1-1990,
the System Interface Standard, describing the read() function.

In the description in section 6.4.1.2, it is unclear exactly in what
state the caller's read buffer is left after the function returns,
in two specific situations:

1. If the read() function returns a value less than "nbyte" but greater
than or equal to zero, indicating that the end-of-file was reached,
must POSIX implementations guarantee that the remaining bytes in the
buffer, from just after the last valid byte transferred to "nbyte"-1,
be left unmodified by the read() function?  Or is the remainder of the
buffer left with undefined contents?

2. Similarly, if the read() function returns an error other than EINTR,
must POSIX implementations guarantee that the caller's read buffer
is left unmodified, or are the contents undefined?  (It seems fairly clear
from paragraph 7 that at least for EINTR the contents must be considered
undefined, since the OS may return -1 anyway after data has been transferred.)

In the (unlikely I would think) case that this issue hasn't already been
dealt with and resolved, my suggested correction would be to state explicitly
that after a partial read, the contents of the remainder of the buffer
is undefined, and after an error, the contents of the entire read buffer
is undefined.  In systems that implement read() using some IPC mechanism
that may have alignment or size granularity restrictions, it is much more
difficult (and in some cases impossible) to implement read() by receiving
data from the IPC system directly into the caller's buffer without copying it,
if the implementation must guarantee that no more bytes in the read buffer
are modified than are actually successfully transferred.

Interpretation response
------------------------
For both of these issues, the standard does not speak to this issue, 
and as such no conformance distinction can be made between alternative	
implementations based on this. This is being referred to the 
sponsor.

Rationale
-------------
Once the buffer has been passed to the system, the state of
the buffer is undefined.

Forwarded to Interpretations group: Apr 10 1996
Forwarded for review: Oct 22 1996
Finalised: Nov 24 1996

PASC Interpretation Ref: pasc-1003.1-77
Topic: rename

Use of the information contained in this unapproved document is at your own risk.

Last update: 23 February,1997

								1003.1-90  #77

 _____________________________________________________________________________

	Interpretation Number:	77
	Topic:               rename
	Relevant Sections:   5.5.3.2.

Interpretation Request:
-----------------------


	Date: Wed, 4 Sep 1996 15:58:08 -0400 (EDT)
	From: "Kirk Russell" <kirk@qnx.com>

(Note line numbers are against 1003.1b-1993, but this is applicable
to 1003.1-90 included in ISO POSIX.1-1996)

The standard states:

		If the old argument and the new argument both refer
		to links to the same existing file, the rename()
		function shall return successfully and perform no
		other action.


Question:

	I am assuming that the rationale for the above clause was to ensure
	that rename("x", "x") does not remove the file "x".  I based my
	assumption on the rationale in subsection B.5.5.3 (lines 3625 through
	3628).  I feel that the above clause is too restrictive.

	If you have two files "x" and "y" that both refer to links to the
	same existing file, then rename("x", "y") will return successfully
	and perform no other action.  I think if would be more logical to
	perform a remove of link "x" in this situation.

	This implementation of rename() would result in the following
	behaviour from the shell prompt (assuming the mv utility is
	compliant with IEEE Std 1003.2-1992 4.43.2 lines 7095 to 7103):

		$ touch x 
		$ ln x y 
		$ ls -li x y 
		186625 -rw-r--r--  2 kirk  techies  0 Aug 23 10:43 x 
		186625 -rw-r--r--  2 kirk  techies  0 Aug 23 10:43 y 
		$ mv x y 
		$ ls -li y 
		186625 -rw-r--r--  1 kirk  techies  0 Aug 23 10:43 y 


	But this implementation may fail some PCTS, since the test suite
	may look at only "inode numbers" to determine if the "x" and "y"
	are links to the same existing file and therefore would expect no
	action to be performed.

	The "4.4BSD Lite" distribution appears to support this
	implementation.  Since rename() was first implemented in 4.xBSD,
	I found it strange that the 4.4BSD implementation of rename()
	would not pass a PCTS. I used the following files a reference:

		/usr/src/sys/ufs/ufs/ufs_vnops.c
		/usr/src/sys/kern/vfs_syscalls.c


Suggested Correction:

	The clause should be changed to:

		If the old argument and the new argument both refer to
		a file with the same name in the same directory, the
		rename() function shall return successfully and perform
		no other action.



Interpretation response
------------------------
The standard clearly states the requirements for rename(), and conforming 
implementations must conform to this.


Rationale
-------------
Interpretations must be a comment on what
the standard actually does say, not what it should say, nor 
what it says incorrectly. Changes to the standard may be submitted
through the revisions process.

Forwarded to Interpretations group: Sep 8 1996
Forwarded for review: Oct 22 1996
Finalised: Nov 24 1996

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

Use of the information contained in this unapproved document is at your own risk.

Last update: 23 February,1997

								1003.1-90  #78

 _____________________________________________________________________________

	Interpretation Number:	78
	Topic:               opendir() error return value
	Relevant Sections:   5.1.2.4

Interpretation Request:
-----------------------

	Date: Mon, 9 Sep 1996 15:10:13 -0400 (EDT)
	From: "Kirk Russell" <kirk@qnx.com>

		Standard:1003.1-1996 (second edition 1996-07-12)
		SubSection:5.1.2.4 (line 118)

		function shall return -1 and set errno to the corresponding
		value


Question:

	The following sources document the return value as NULL:
		1003.1-1996 subsection 5.1.2.3		line 94
		1003.1b-1993 subsection 5.1.2.3		line 74
		1003.1b-1993 subsection 5.1.2.4		line 96
		2003.1-1992 subsection 5.1.2.2.4	line 253

	Does line 118 of std 1003.1-1996 subsection 5.1.2.4 indicate
	a new contradiction or a typographical error?

Suggested Correction:

	The clause should be changed to:

		function shall return NULL and set errno to the corresponding
		value



Interpretation response
------------------------
This is a typographical error. The published IEEE Std 1003.1-1996
is inconsistent with IEEE Std 1003.1-1990 and IEEE Std 1003.1b-1993.

Clauses 5.1.2.4 ll 102 & 114  should be changed to say:
		function shall return NULL and set errno to the corresponding
		value

It is recommended that this be fixed by applying the IEEE erratta process.

Rationale
-------------
The approved IEEE Std 1003.1-1990  does not include
this wording. IEEE Std 1003.1-1996 is a re-publication
of 1003.1-1990 merged together with the amendments. Since
there are intended to be no substantive changes apart
from the merging of the amendments, this would appear to be
a problem introduced with the merge.

Forwarded to Interpretations group: Sep 17 1996
Review start: Oct 22 1996
Finalised: Nov 24 1996