A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=657 
====================================================================== 
Reported By:                philip-guenther
Assigned To:                ajosey
====================================================================== 
Project:                    1003.1(2008)/Issue 7
Issue ID:                   657
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Objection
Priority:                   normal
Status:                     Under Review
Name:                       Philip Guenther 
Organization:               OpenBSD 
User Reference:              
Section:                    fmemopen 
Page Number:                867 
Line Number:                28775 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2013-02-08 22:46 UTC
Last Modified:              2023-10-16 16:06 UTC
====================================================================== 
Summary:                    Conditions under which fmemopen() write a NUL to the
buffer are insufficiently specified
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0000396 fmemopen vs. 'b' mode flag
related to          0000456 mandate binary mode of fmemopen
related to          0000818 fmemopen should allow 0-size buffer
====================================================================== 

---------------------------------------------------------------------- 
 (0006535) geoffclare (manager) - 2023-10-16 16:06
 https://austingroupbugs.net/view.php?id=657#c6535 
---------------------------------------------------------------------- 
Interpretation response
------------------------
The standard is unclear on this issue, and no conformance distinction can
be made between alternative implementations based on this. This is being
referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

Page and line numbers are for Issue 8 draft 3.

Change "<i>size</i>" (when talking about the argument) to "<i>max_size</i>"
throughout.
Change "size" (when talking about the last position in the buffer) to "end
position" throughout.

Change on P961, L32741:<blockquote>Open the stream for update (reading and
writing). Truncate the buffer contents.</blockquote>to:<blockquote>Open the
stream for update (reading and writing).</blockquote>
Change P961, L32744-32745 from:<blockquote>If the <i>mode</i> argument
includes 'b', then the stream shall be in binary mode; otherwise the stream
shall be in text mode.</blockquote>to:<blockquote>If the <i>mode</i>
argument begins with 'w' and <i>max_size</i> is not zero, the buffer
contents shall be truncated by writing a null byte at the beginning. If the
<i>mode</i> argument includes 'b', the results are
implementation-defined.</blockquote>
Change on P961, L32758-32762:<blockquote>The stream shall also maintain the
size of the current buffer contents; use of <i>fseek</i>() or
<i>fseeko</i>() on the stream with SEEK_END shall seek relative to this
size. If <i>mode</i> starts with 'r' or includes 'b', the size shall be set
to the value given by the <i>size</i> argument and shall not change.
Otherwise, the stream is in text mode and writable, and the size shall be
variable; for modes w and w+ the initial size shall be zero and for modes a
and a+ the initial size shall be:</blockquote>to:<blockquote>The stream
shall also maintain the end position of the current buffer contents; use of
<i>fseek</i>() or <i>fseeko</i>() on the stream with SEEK_END shall seek
relative to this end position. If <i>mode</i> starts with 'r' the end
position shall be set to the value given by the <i>max_size</i> argument
and shall not change. Otherwise, the stream is writable and the end
position shall be variable; for modes w and w+ the initial end position
shall be zero and for modes a and a+ the initial end position shall
be:</blockquote>
Change on P962, L32775-32776:<blockquote>When a stream open for writing in
text mode is flushed or closed, a null byte shall be written at the current
position or at the end of the buffer, depending on the size of the
contents. If a stream open for update in text mode is flushed or closed and
the last write has advanced the current buffer size, a null byte shall be
written at the end of the buffer if it fits. If a stream is opened in
binary mode, no additional null byte shall be
written.</blockquote>to:<blockquote>When a stream open for update (the
<i>mode</i> argument includes '+') or for writing only is successfully
written and the write advances the current buffer end position, a null byte
shall be written at the new buffer end position if it fits.</blockquote>
Change on P963, L32822-32828:<blockquote>Unlike <i>fopen</i>(), where a 'b'
in the <i>mode</i> argument is required to have no effect,
<i>fmemopen</i>() distinguishes between text and binary modes. Text mode
guarantees that the underlying memory will always be null terminated after
any write operation, and tracks the growth of the largest position written
to up to that point; while binary mode only modifies the underlying buffer
according to direct writes, while seeking relative to the full buffer size.
The combination of append and binary modes is not commonly used, since any
attempt to write to such a stream will necessarily fail because the stream
does not dynamically grow beyond the initial
size.</blockquote>to:<blockquote>Implementations differ as regards how a
'b' in the <i>mode</i> argument affects the behavior. For some the 'b' has
no effect, as is required for <i>fopen</i>(); others distinguish between
text and binary modes.

Note that <i>buf</i> will not be null terminated if<i>max_size</i> bytes
are written to the memory stream.  Applications wanting to guarantee that
the buffer will be null terminated need to call <i>fmemopen</i>() with
<i>max_size</i> set to one byte smaller than the actual size of <i>buf</i>
and set <i>buf<i>[<i>max_>size</i>] to a null byte. </blockquote> 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2013-02-08 22:46 philip-guentherNew Issue                                    
2013-02-08 22:46 philip-guentherStatus                   New => Under Review 
2013-02-08 22:46 philip-guentherAssigned To               => ajosey          
2013-02-08 22:46 philip-guentherName                      => Philip Guenther 
2013-02-08 22:46 philip-guentherOrganization              => OpenBSD         
2013-02-08 22:46 philip-guentherSection                   => fmemopen        
2013-02-08 22:46 philip-guentherPage Number               => 867             
2013-02-08 22:46 philip-guentherLine Number               => 28775           
2013-02-14 16:55 eblake         Relationship added       related to 0000396  
2013-02-14 16:55 eblake         Relationship added       related to 0000456  
2013-03-28 23:54 philip-guentherNote Added: 0001506                          
2014-01-30 04:06 eblake         Relationship added       related to 0000818  
2023-10-16 16:06 geoffclare     Note Added: 0006535                          
======================================================================


  • [1003.1(2008... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to