Use of the information contained in this unapproved document is at your own risk
.Last update: 23 March,1998
1003.1b-93 #13
_____________________________________________________________________________
Interpretation Number: XXXX
Topic: shared memory objects
Relevant Sections: Page 543, line 7674, Section B.12.3.1
PASC Interpretation Request: (Defect Report)
----------------------------
From: W. Richard Stevens ( rstevens@kohala.com )
Date: 1997 Dec 05
------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard
or DIS final text, if applicable):
System Interface Standard:IEEE Std 1003.1-1990 (ISO 9945-1:1990)
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
1
Error=1 , Omission=2, Clarification=3
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table
numbers):
Page 543, line 7674, Section B.12.3.1
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived
problem):
Are shared memory objects initialized to 0?
The Rationale states "The standard specifies that memory objects
have initial contents of zero when created" (page543) but I
cannot find where
in the standard this is specified.
Page 282, line 585 does specify that "The shared memory object shall
have a size of zero".
But if you then read on page 142 under ftruncate(), lines 1031-1039
are divided into two pieces: regular files and shared memory
objects. The sentence on lines 1035-1036 "If the file is
extended, the extended area shall appear as if it were zero-filled"
refers to regular files and not shared memory (in my reading of it).
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
Either correct the sentence in the Rationale or correct the
description of ftruncate().
------------------------------------------------------------------------
Interpretation response
------------------------
The standard is silent for shm_open() as to the contents
of the storage that is accessed by the file descriptor.
The rationale quoted is informative only and not part of the
normative text.
Rationale
-------------
From 6.4.1.2 (read()):
For any portion of a regular file, prior to end-of-file, that
has not been written, read() shall return bytes with value zero."
This does not require that the bytes be initialized. Indeed, the
needed storage need not have been allocated to the file. Regular files
can have holes in them, and the holes appear as if zero-filled when
they're read.
The quoted text from the description of ftruncate() specifies the same
behavior when the file size is changed by ftruncate() rather than by
lseek() followed by write().
This requirement applies only to regular files, not to shared memory
objects.
The description of shm_open() (12.3.1.2) is silent as to the contents
of the storage that is accessed by the file descriptor.
Notes to project editor (not part of this interpretation)
-----------------------------------------------------------
The final paragraph of B.12.3.1 should be removed when the Standard
is next updated.
Forwarded to Interpretations group: Dec 6 1997
Proposed resolution circulated: Feb 18 1998
Finalised: Mar 22 1998