Re: [PATCH] mingw: make stderr unbuffered again

From: Johannes Sixt <j6t@kdbg.org>
Date: Feb 15, 2017, 20:45 UTC
Message-ID: <0275af7b-eb7a-1094-a891-674300175e56@kdbg.org>
In-Reply-To: <alpine.DEB.2.20.1702151312330.3496@virtualbox>

Am 15.02.2017 um 13:32 schrieb Johannes Schindelin:

Show 15 quoted lines

> On Tue, 14 Feb 2017, Johannes Sixt wrote:
>> Am 14.02.2017 um 15:47 schrieb Johannes Schindelin:
>>> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>>>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>>>> What we forgot was to mark stderr as unbuffered again.
>>
>> I do not see how the earlier patch turned stderr from unbuffered to
>> buffered, as it did not add or remove any setvbuf() call. Can you
>> explain?
>
> [ motivation and history of js/mingw-isatty snipped ]
>
> So instead of "bending" the target HANDLE of the existing stdout/stderr
> (which would *naturally* have kept the buffered/unbuffered nature as-is),
> we now redirect with correct API calls.

Your statement implies that at the time when winansi_init() begins, stdio is already initialized and the buffered/unbuffered state has been set for stderr. I would think that this is true.

Then we swap out the file handle underlying stderr in swap_osfhnd() using dup2(). Why would that change the buffered state of stdio?

Show 6 quoted lines

> And the patch I provided at the
> bottom of this mail thread reinstates the unbuffered nature of stderr now
> that it gets reopened.
>
> Hopefully that makes it clear why the setvbuf() call is required now, but
> was previously unnecessary?

Unfortunately, no. I do not see how dup2() causes a change in stdio state. I must be missing something (and that may be a basic misunderstanding of how stdio is initialized).

-- Hannes