On Thu, 2017-11-30 at 16:13 +0100, Andreas Schwab wrote:
> On Nov 30 2017, Thomas Adam <thomas@xxxxxxxxxx> wrote:
>
> > On Thu, Nov 30, 2017 at 02:55:35PM +0100, Lars Schneider wrote:
> > >
> > > > On 29 Nov 2017, at 19:35, Thomas Adam <thomas@xxxxxxxxxx> wrote:
> > > >
> > > > On Wed, Nov 29, 2017 at 03:37:50PM +0100, lars.schneider@xxxxxxxxxxxx wrote:
> > > > > + if (print_waiting_for_editor) {
> > > > > + fprintf(stderr, _("hint: Waiting for your editor input..."));
> > > > > fflush(stderr);
> > > >
> > > > Just FYI, stderr is typically unbuffered on most systems I've used, and
> > > > although the call to fflush() is harmless, I suspect it's not having any
> > > > effect. That said, there's plenty of other places in Git which seems to think
> > > > fflush()ing stderr actually does something.
> > >
> > > I agree with the "unbuffered" statement. I am surprised that you expect fflush()
> > > to do nothing in that situation... but I am no expert in that area. Can you
> > > point me to some documentation?
> >
> > Because stderr is unbuffered, it will get printed immediately.
>
> POSIX only requires stderr to be "not fully buffered". If it is line
> buffered, the message may not appear immediately.
>
I guess Junio's reply for the same "unbuffered" question I asked for an
earlier version of this patch (now, a series) might be relevant here,
> > Being curious again, is flushing 'stderr' required ? AFAIK, 'stderr'
> > is unbuffered by default and I didn't notice any calls that changed
> > the buffering mode of it along this code path.
>
> "By default" is the key phrase. The code is merely being defensive
> to changes in other area of the code.
cf. <xmqq8tf3oz3n.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
--
Kaartic
