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

[Adhemerval Zanella Netto]

On 04/05/26 13:54, Alex Gao wrote:
> 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.
Alright, sounds reasonable. Thanks for working on this.