Created attachment 6271 [details] Testcase. Attached testcase segfaults with Fedora 16 glibc and trunk as well. The problem is that fgetws_unlocked calls _IO_getwline which is just return _IO_getwline_info (fp, buf, n, delim, extract_delim, (wint_t *) 0); however, in _IO_getwline_info is _IO_ssize_t len = (fp->_wide_data->_IO_read_end - fp->_wide_data->_IO_read_ptr); whereas (gdb) p fp->_wide_data $6 = (struct _IO_wide_data *) 0x0
That's because fmemopen does not support wide character functions. There's open_wmemstream that is a close replacement.
Yes, but I think we shouldn't just segfault.
For that I guess it would be simple to make all the wide char functions return NULL if they're called on an fp with _mode == -1.
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.
At least in POSIX, open_wmemstream does not allow reading, so it is not a replacement for fmemopen.