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

Last update: 10 April,2001

                                                                1003.1-90 #74

 _____________________________________________________________________________

	Interpretation Number:	XXXX
	Topic:			tmpfile
	Relevant Sections:	8.2.3.9
	Classification:		


Interpretation Request: (Defect Report)
-----------------------

This is a request for interpretation of IEEE standard 1003.1-1990 (ISO
9945-1:1990)


Section 8.2.3.9 tmpfile(), line 398-399 describes the tmpfile()
function as "tmpfile() shall allocate a file descriptor as fopen() does".

The fopen() descriptions states "The fopen() function shall allocate
a file descriptor as open() does". 

Many common implementations return a file descriptor for an unlinked file.  
Is it conforming for tmpfile() to call open() with a mode of zero, so
that the temporary file created in the file namespace prior to
unlinking be protected from access by other users ?

POSIX 2003.1 has an assertion  8.2.3.9-05(B) that would say
that it is not conforming; the assertion states:

"When a call to tmpfile() creates a file, then the file permission bits
are set to allow both reading and writing for owner, for group, and
for other users except for those bits set in the process's file mode
creation mask. No execute (search) permission bits are set. The user
ID of the file is set to the process's effective user ID and the group
ID of the file is set to the process's effective group ID or to the
group owner of its parent directory."


This assertion relates to the references between tmpfile() -> fopen() -> open().
It appears to us that this requirement is beyond the specification in
P1003.1 for tmpfile() which is to allocate a file descriptor and that this
requirement in P2003.1 should be noted as incorrect.

PASC Interpretation for 1003.1-1990 
-----------------------------------
No this is not conforming.  The standard clearly states in section 8.2,
Line 193-197:
 
      "All functions specified in the C Standard as creating a file
      shall do so as if they called the creat() function with ... a
      value of S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH for
      the mode argument."

Rationale for Interpretation:
-----------------------------

This requirement of P2003.1 reflects the actual wording of the
standard.  While the standard requires these permission bits be set, it is
not clear that they offer any benefit to application portability, since the
only possible impact of not conforming to this requirement is on the results
returned by fstat().  The open file descriptor that the process owns will
continue to be accessible to the requesting process and all processes that
inherit it.

This interpretation will be refered to the sponsor for consideration in a 
future revision of the standard.

One possible legal implementation that achieves the desired
effect would be to create the file with no permissions, unlink, and then
use the fchmod() function from 1003.1-1994 to change the mode of the file
to the permissions required by the standard, (user, group, other permissions
to RW, modified by the umask value) before returning from the tmpfile( ) 
function.


Forwarded to Interpretation group: Aug 30 1995
Initially finalised: Nov 21 1995                    
Finalised: 20 July 1997