From ajosey@rdg.opengroup.org Mon Mar 23 09:40:45 1998 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 JAA04501 for ; Mon, 23 Mar 1998 09:40:43 +0100 Received: by mailgate.rdg.opengroup.org; id AA07020; Mon, 23 Mar 1998 08:42:54 GMT Message-Id: <9803230842.AA07020@mailgate.rdg.opengroup.org> Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Mon Mar 23 08:42 GMT 1998 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA12390; Mon, 23 Mar 1998 08:27:55 GMT From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Mon, 23 Mar 1998 08:27:54 +0000 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: Defect Report concerning: IEEE Std. 1003.1b-1993, ISO/IEC 9945-1:1990 AMD 1 For the attention of the WG15 Project Editors: Defect Report concerning: IEEE Std. 1003.1b-1993, ISO/IEC 9945-1:1990 AMD 1 - Realtime Defect report number: IS9945-1:1996 #1b-13 Clause: Page 543, line 7674, Section B.12.3.1 PASC Interpretation Ref: pasc-1003.1b-13 Topic: shared memory objects ---------------------------------------------------------------------------- 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 WG15 Status Block (official use only): ------------------------------------------------------------------------ 1 Defect report number: IS9945-1:1996 #1b-13 2 Submitter: IEEE PASC March 23 1998 3 Addressed to: JTC1/SC22 /WG15 editor's group on IS 9945-1 4 WG secretariat: ------------------------------------------------------------------------ 5 Date circulated by WG secretariat: 6 Deadline on response from editor: ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): System Interface Standard:IEEE Std 1003.1b-1993 Realtime Extension (ISO 9945-1:1996) ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------ 12 Editor's response (any material proposed for processing as a technical corrigendum to, an amendment to, or a commentary on the International Standard or DIS final text is attached separately to this completed report): See interpretation response and notes to project editor above ------------------------------------------------------------------------ Forwarded to Interpretations group: Dec 6 1997 Proposed resolution circulated: Feb 18 1998 Finalised: Mar 22 1998 ----- 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