[Bug libc/12836] fmemopen(buf,size,"w+b") isn't binary

["eblake at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12836

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #3 from Eric Blake <eblake at redhat dot com> 2011-07-27 17:59:04 UTC ---
(In reply to comment #2)
> An(In reply to comment #0)
> > The documented behavior of fmemopen behaving in binary mode if 'b' was present
> > in mode does not actually happen if 'b' is not in mode[1].  For consistency
> > with fopen and friends, 'wb+' and 'w+b' should have identical effect.
> 
> Who says that?

The Austin Group:

http://austingroupbugs.net/view.php?id=456

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).

>  Any such change would mean that either we'd have to change the
> version of the fmemopen interface and prevent code compiled now to use fmemopen
> from running with older glibcs.

This one-liner patch is forwards compatible:

Old programs have four defined choices documented in 'man fmemopen' when mode
starts with 'w':

fmemopen (,"w") - text mode
fmemopen (,"wb") - binary mode
fmemopen (,"w+") - text mode
fmemopen (,"wb+") - binary mode
all other strings starting with w have undefined behavior

New programs will have five defined choices:
fmemopen (,"w") - text mode
fmemopen (,"wb") - binary mode
fmemopen (,"w+") - text mode
fmemopen (,"wb+") - binary mode
fmemopen (,"w+b") - binary mode
all other strings starting with w have undefined behavior

Old programs should not have been relying on undefined behavior of "w+b", and
this patch merely adds one new mode, without changing the behavior of any
existing defined modes.

I don't know why you are complaining about this not being backwards compatible.
 I agree that a program compiled against glibc 2.15 (assuming that is the glibc
version where this patch is added) but run against glibc 2.14 would do the
wrong thing for w+b if fmemopen is not versioned for this fix.  But when have
we ever supported that type of back compatibility?  In general, when you
compile against a newer glibc, there are no promises that you can run your
program against older glibc.  Furthermore, did you even version bump fmemopen
when you added support for 'b' in the first place in bug 6544 - that is, if I
use "wb" compiled against glibc 2.9 but then run against glibc 2.8, will I get
a link failure due to a missing versioned symbol, or just a silent change in
behavior because I was tickling behavior that was undefined in 2.8?  Likewise,
did you version bump fopen when you fixed a mis-parse of the mode string in bug
12685?

At the end of the day, this patch is just a one-liner fix to a mis-parse of the
mode string, and not a version compatibility nightmare that you are trying to
make it out to be.

>  And for what?  Just so that you get
> "consistency"?  No good reason.

It's more than just "consistency", it is so that new programs will be able to
use the new requirements to be added in Issue 8 of POSIX.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.