Created attachment 6941 [details] partial regression test for open_memstream The IEEE Std 1003.1-2008 (aka POSIX-2008) says this in its description of open_memstream: -------- The stream shall maintain a current position in the allocated buffer and a current buffer length. The position shall be initially set to zero (the start of the buffer). Each write to the stream shall start at the current position and move this position by the number of successfully written bytes for open_memstream() or the number of successfully written wide characters for open_wmemstream(). The length shall be initially set to zero. If a write moves the position to a value larger than the current length, the current length shall be set to this position. In this case a null character for open_memstream() or a null wide character for open_wmemstream() shall be appended to the current buffer. For both functions the terminating null is not included in the calculation of the buffer length. After a successful fflush() or fclose(), the pointer referenced by bufp shall contain the address of the buffer, and the variable pointed to by sizep shall contain the smaller of the current buffer length and the number of bytes for open_memstream(), or the number of wide characters for open_wmemstream(), between the beginning of the buffer and the current file position indicator. -------- So, if you write to the stream, seek past the end, then close it without writing again, the size location should be set to the end of the furthest write ("smaller of the current buffer length and <...>"), not the seek position. In glibc 2.17, it instead returns the seek position.
The behavior of fseek(fp, offset, SEEK_END) also seems...odd. My expectation, given the wording of the spec, is that it would be relative to the buffer length (as defined by the spec) but it seems to be relative to something bigger than that, the actual allocated buffer size, perhaps? Isn't the stream created by open_memstream() supposed to behave like an in-memory version of a temp file, so seeks from SEEK_END should be relative to just past the last written position?
I agree that returned size from fflush/fclose on a open_memstream FILE is not correct for current GLIBC code. As stated in first comment, final size is being based on current buffer position defined by fseek instead of current minimum size from written bytes. However, the provided testcase also are not correct: 134 if (size != OFFSET + sizeof(hello)-1) { 135 warnx("failed, size %zu should be %lu. (18)", 136 size, (unsigned long)(OFFSET + sizeof(hello)-1)); 137 failures++; 138 } The final size should be '5', not 16389 because there is not write operation between fflush at line 95 and final fclose at line 129. Recall that fseek at line 124 would move the internal position, but according to POSIX "the variable pointed to by sizep shall contain the *smaller* of the current buffer length and the number of bytes". I am working on correcting this issue and other open_memstream issues (BZ#18241 and BZ#20181).
Created attachment 12657 [details] memstream_open test for fflush vs. fclose Beginning with glibc 2.25 and up to the current development version, fflush() vs. fclose() behave differently after a seek + write, so this is still broken. The attached test program gives the following output: The following two lines should be identical: size 7 strlen 26 buf 'ABCDEFGhijklmnopqrstuvwxyz' size 7 strlen 7 buf 'ABCDEFG'