[Bug stdio/13822] fmemopen cannot handle wide chars

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> 2012-10-25 18:12:23 UTC ---
Per the standard, calling wide functions on a byte-oriented stream or byte
functions on a wide-oriented stream is not an error; it's undefined behavior.
Therefore, the crash is justified if the stream is byte-oriented.

However, I see nothing in the standard that requires or allows the stream
obtained by fmemopen to be initially byte-oriented, so presumably the POSIX
standard, as written, requires it to be initially unoriented. Unlike
open_wmemstream, which generates a wchar_t string, I think the natural behavior
for fmemopen if put in a wide-oriented mode would be to convert to multibyte
characters, and work with file offsets in bytes, just like an ordinary file
(this is the normal behavior for stream functions; the open_wmemstream behavior
is pathological). This is how my implementation of fmemopen in musl works (not
by design; just as a consequence of how our wide functions work).

Of course, if the glibc maintainers think fmemopen should return a
byte-oriented stream, I would not object to this, but I think that calls for
opening a defect report with the Austin Group and requesting that POSIX specify
that fmemopen returns a byte-oriented stream, or at least that it MAY return a
byte-oriented stream, in which case calling wide functions on it would invoke
undefined behavior.

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