[PATCH v2] libio: Ignore setbuf for open_memstream [BZ #34019]

[Alex Gao]

On 2026/5/4 20:04, Adhemerval Zanella Netto wrote:
> 
> 
> On 01/05/26 13:24, Rocket Ma wrote:
>>> Wouldn't this change the behavior or setbuf (NULL, ..) and setbuf (..., 0)
>>> to not be _IO_UNBUFFERED?
>>>
>>> I think it does not seems to matter though, since the resulting buffer operated
>>> by open_memstream can only be accessible after a fflush/fclose.  The
>>> setbuf/setvbuf would only be a way to optimize the stdio buffer flush to
>>> final one, which I am also not fully sure it would matter here.
>>>
>>
>> Referencing POSIX standard[1], fflush and fclose are explicitly
>> mentioned when describing `bufp` and `sizep`, which may indicate that
>> user shall always flush the stream. But the standard does not mention
>> the behavior of setbuf. I'm also not sure if we should allow user to
>> setbuf.
>>
>> [1]: https://pubs.opengroup.org/onlinepubs/9799919799/functions/open_memstream.html
> 
> I think ignoring set{v}buf makes sense here, we can make it orthogonal to other
> stream by the current POSIX description makes invisible to user anyway.

Thanks, that makes sense.

I will treat setbuf/setvbuf as orthogonal to the memory-stream result 
buffer.The backing buffer of open_memstream/open_wmemstream is the 
growable result object itself, not discardable. Therefore the generic 
buffering operation is not appropriate here: it must not reset the 
get/put areas.

While adding setvbuf coverage, I confirmed that the current hook change 
covers the setvbuf paths that reach _IO_SETBUF, but I also found one 
related case:

setvbuf(fp, NULL, _IOFBF, 0)

This can bypass the setbuf hook and go through doallocate instead. In 
that path default wide buffering code may still disturb the wide result 
buffer. I will send a separate patch(v3) for wmemstream doallocate path.