Created attachment 12812 [details] memstream-test.c The attached memstream-test.c gives expected fseek() behavior on streams created with fopen() and with fmemopen(), and also with open_memstream in glibc 2.12 and 2.17. But in glibc 2.28 an open_memstream() gives incorrect behavior
Correction: open_memstream() gives incorrect behavior in all those glibc (2.12, 2.17, 2.28, and also 2.31). The incorrect behavior varies. Also, fmemopen() gave incorrect behavior in older glibc, but it seems okay now and our only concern is with open_memstream().
I'm seeing this as well, I believe: When the FILE *returned by open_memstream is closed, the buffer that is returned is truncated to be as large as the current file offset, not the length of the data that has been written (and also not the actual size of the buffer that has been allocated). Furthermore, fseek (file, 0, SEEK_END) does not seek to the end of the written buffer. It's possible this behavior is documented in the standard, but it's not documented in the manpage.
We started an RFC in 20220 about open_memstream behaviour to harmonize: https://www.openwall.com/lists/libc-coord/2020/09/24/1 There is an Austin Group ticket open for clarification: https://www.austingroupbugs.net/view.php?id=1406