Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000456 [1003.1(2008)/Issue 7] System Interfaces Objection Enhancement Request 2011-06-02 18:55 2024-06-11 08:53
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Eric Blake
Organization Red Hat
User Reference ebb.fmemopen.2
Section fmemopen
Page Number 866
Line Number 28742
Interp Status ---
Final Accepted Text See Note: 0000878
Summary 0000456: mandate binary mode of fmemopen
Description 0000396 changes TC1 to allow, but not require, glibc behavior of the
'b' flag to fmemopen. However, the idea of binary stream editing is
useful enough to be worth standardizing in Issue 8.

The proposed resolution starts from the wording in 396. The TC1 wording
requires that fmemopen( ) accept the same mode strings as fopen( );
but 0000411 adds the 'x' and 'e' mode flags which do not apply to
memory strings (O_CLOEXEC and O_EXCL only apply to underlying files).

Note that glibc 2.13 accepts 'wb+' but not 'w+b' for triggering binary
mode; this was raised as a glibc bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=12836 [^]
Desired Action At lines 28742-28750 [XSH fmemopen DESCRIPTION], replace the existing
text (from "The mode argument..." to "at end-of-file", whether from
Issue 7 or from the TC1 wording) with:

The mode argument points to a string. If the string is one of
the following, the file shall be opened in the indicated mode.
Otherwise, the behavior is undefined.

r or rb Open the stream for reading.
w or wb Open the stream for writing.
a or ab Append; open the stream for writing.
r+ or rb+ or r+b Open the stream for update (reading and writing).
w+ or wb+ or w+b Open the stream for update (reading and writing).
  Truncate the buffer contents.
a+ or ab+ or a+b Append; open the stream for update (reading and
  writing).

At line 28751, replace TC1 wording:

Implementations shall accept all mode strings allowed by fopen(),
but the use of the character 'b' shall produce implementation-defined
results, where the resulting FILE * need not behave the same as if 'b'
were omitted.

with:

If the mode argument includes 'b', then the stream shall be in
binary mode; otherwise the stream shall be in text mode.

At line 28762, change Issue 7 wording (untouched in TC1):

The stream also maintains the size of the current buffer contents.
For modes r and r+ the size is set to the value given by
the size argument. For modes w and w+ the initial
size is zero and for modes a and a+ the initial size is
either the position of the first null byte in the buffer or the value
of the size argument if no null byte is found.

to:

The stream also maintains the size of the current buffer contents;
use of fseek() or fseeko() on the stream with SEEK_END seeks relative
to this size. If mode starts with 'r' or includes 'b', the
size is set to the value given by the size argument and does
not change. Otherwise, the stream is in text mode and writable, and
the size is variable; for modes w and w+ the initial
size is zero and for modes a and a+ the initial size is
either the position of the first null byte in the buffer or the value
of the size argument if no null byte is found.

At line 28775, change Issue 7 wording (untouched in TC1):

When a stream open for writing is flushed or closed, a null byte is
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 is flushed or
closed and the last write has advanced the current buffer size, a null
byte is written at the end of the buffer if it fits.

to:

When a stream open for writing in text mode is flushed or closed, a
null byte is 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 is written at the end
of the buffer if it fits. If a stream is opened in binary mode, no
additional null byte is written.

At line 28819 [APPLICATION USAGE], change "None." to:

Unlike fopen( ), where a 'b' in the mode argument is required to
have no effect, fmemopen( ) distinguishes between text and binary modes.
Text mode guarantees that the underlying memory will always be
NUL-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.

This standard intentionally leaves the behavior of 'e' and 'x' in the
mode argument as unspecified; implementations might silently ignore
them so that fmemopen( ) may accept the same mode strings as fopen( ),
or may reject them as invalid.

At line 28824 [FUTURE DIRECTIONS], change the TC1 wording:

A future revision of this standard may mandate specific behavior when
the mode argument includes 'b'.

back to the Issue 7 "None."
Tags issue8
Attached Files

- Relationships
related to 0000411Closedajosey 1003.1(2008)/Issue 7 adding atomic FD_CLOEXEC support 
related to 0000461Closedajosey 1003.1(2008)/Issue 7 missing shalls in interfaces new to Issue 7 
related to 0000657Closedajosey 1003.1(2008)/Issue 7 Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified 
related to 0001406Closed 1003.1(2016/18)/Issue7+TC2 clarification of SEEK_END when current pointer doesn't match buffer size 
child of 0000396Closedajosey 1003.1(2008)/Issue 7 fmemopen vs. 'b' mode flag 

-  Notes
(0000878)
eblake (manager)
2011-06-30 21:38

 Updated actions, assuming that both 0000396 and 0000461 are
incorporated into TC1. Line numbers still reflect Issue 7, but
the text now reflects the cumulative effects of both TC1 bugs
as of draft 2 (the first attempt only reflected 0000396).



At lines 28743-28750 [XSH fmemopen DESCRIPTION], undo the TC1 changes
(XSH/TC1/D2/0136), and replace the existing text (in Issue 7, the
6 rows from "r or rb" to "at the first null byte") with:

r or rb Open the stream for reading.
w or wb Open the stream for writing.
a or ab Append; open the stream for writing.
r+ or rb+ or r+b Open the stream for update (reading and writing).
w+ or wb+ or w+b Open the stream for update (reading and writing).
  Truncate the buffer contents.
a+ or ab+ or a+b Append; open the stream for update (reading and
  writing).

At line 28751, replace TC1 wording (XSH/TC1/D2/0137):

Implementations shall accept all mode strings allowed by fopen(),
but the use of the character 'b' shall produce implementation-defined
results, where the resulting FILE * need not behave the same as if 'b'
were omitted.

with:

If the mode argument includes 'b', then the stream shall be in
binary mode; otherwise the stream shall be in text mode.

At line 28762, change the TC1 wording (XSH/TC1/D2/0139):

...For modes r and r+ the size shall be set to the value given by
the size argument. For modes w and w+ the initial size shall be zero
and for modes a and a+ the initial size shall be either the position
of the first null byte in the buffer or the value of the size
argument if no null byte is found.

to:

...If mode starts with 'r' or includes 'b', the size shall be
set to the value given by the size 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 either the position of the first null byte in the
buffer or the value of the size argument if no null byte is
found.

At line 28775, change TC1 wording (XSH/TC1/D2/0142):

When a stream open for writing 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 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.

to:

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.

At line 28819 [APPLICATION USAGE], change "None." to:

Unlike fopen( ), where a 'b' in the mode argument is required to
have no effect, fmemopen( ) distinguishes between text and binary modes.
Text mode guarantees that the underlying memory will always be
NUL-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.

This standard intentionally leaves the behavior of 'e' and 'x' in the
mode argument undefined; implementations might silently ignore them so
that fmemopen( ) may accept the same mode strings as fopen( ), or may
reject them as invalid.

At line 28824 [FUTURE DIRECTIONS], change the TC1 wording
(XSH/TC1/D2/0143):

A future revision of this standard may mandate specific behavior when
the mode argument includes 'b'.

back to the Issue 7 "None."
(0006506)
eblake (manager)
2023-10-02 16:12

 glibc 2.22 dropped all support for 'b' along with changing a number of other bug fixes in their fmemopen() implementation. Standardizing a 'b' mode in Issue 8 that differs from current glibc behavior of ignoring 'b' would thus not match existing practice.

- Issue History
Date Modified Username Field Change
2011-06-02 18:55 eblake New Issue
2011-06-02 18:55 eblake Status New => Under Review
2011-06-02 18:55 eblake Assigned To => ajosey
2011-06-02 18:55 eblake Name => Eric Blake
2011-06-02 18:55 eblake Organization => Red Hat
2011-06-02 18:55 eblake User Reference => ebb.fmemopen.2
2011-06-02 18:55 eblake Section => fmemopen
2011-06-02 18:55 eblake Page Number => 866
2011-06-02 18:55 eblake Line Number => 28742
2011-06-02 18:55 eblake Interp Status => ---
2011-06-02 19:12 eblake Relationship added child of 0000396
2011-06-02 19:13 eblake Relationship added related to 0000411
2011-06-02 19:13 eblake Tag Attached: issue8
2011-06-07 20:59 eblake Relationship added related to 0000461
2011-06-15 15:09 msbrown Resolution Open => Future Enhancement
2011-06-30 21:38 eblake Note Added: 0000878
2011-09-08 15:41 Don Cragun Final Accepted Text => See Note: 0000878
2011-09-08 15:41 Don Cragun Status Under Review => Resolved
2011-09-08 15:41 Don Cragun Resolution Future Enhancement => Accepted As Marked
2013-02-14 16:55 eblake Relationship added related to 0000657
2020-03-05 15:01 geoffclare Status Resolved => Applied
2020-09-29 20:55 Don Cragun Relationship added related to 0001406
2023-10-02 16:12 eblake Note Added: 0006506
2024-06-11 08:53 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker