[bug-diffutils] bug#20062: bug#20062: bug#20062: bug#20062: bug#20062: [PATCH] diff: add support for --color

[Paul Eggert]

Giuseppe Scrivano wrote:
> Paul Eggert <address@hidden> writes:
>
> > Giuseppe Scrivano wrote:
> > >    Would block signals between a set_*_color_context and
> > > reset_color_context be enough or do we need more granularity (there are
> > > many places where printf is used in the code)?
> >
> > No, for reasons Eric described: output is buffered.
>
> can't we solve this by flushing the output before enabling signals?

"enabling"?  Do you mean, flushing the output when a signal is caught?  No, that 
won't work, as stdio is not safe in the presence of signals.  Or do you mean 
fflush the output before unblocking signals?  Yes, that will work, but it's slow.

> we already had this discussion about an older version of the patch where
> signals were processed after every line.  We agreed that one difference
> between ls and diff is that ls has a limit on the line length, while
> diff hasn't such a limit and as you noted, it is bound only to the
> available memory.  This was the reason for reacting to signals as soon
> as diff receives one.

Sorry, I don't remember that discussion.  Yes, the point is a valid one, and 
needs to be addressed.

> Either we block signals or we catch them and process as ls does (calling
> 'process_signals' periodically) that problem will still be present.

True.  However, blocking signals means we'll need to periodically 
fflush-unblock-block, which will slow us down; the whole point of stdio is 
efficiency via buffering, after all.  Doing it the 'ls' way avoids this 
overhead, as we'll need to fflush only when a signal has actually arrived, plus 
we avoid the syscall overhead of periodic unblock-block.