GNU bug report logs - #20062
[PATCH] diff: add support for --color

Previous Next

Full log

Message #164 received at 20062 <at> debbugs.gnu.org (full text, mbox):

From: Giuseppe Scrivano <gscrivan <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eric Blake <eblake <at> redhat.com>, 20062 <at> debbugs.gnu.org
Subject: Re: [bug-diffutils] bug#20062: bug#20062: bug#20062: bug#20062:
 [PATCH] diff: add support for --color
Date: Sat, 12 Sep 2015 13:40:08 +0200

Paul Eggert <eggert <at> cs.ucla.edu> 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?  In
case of using buffered output we would still need to flush it to be sure
the reset sequence is printed.


> I suggest looking at the source code of GNU ls and seeing how it does
> things. In normal execution it never blocks signals at all.  (It
> temporarily blocks signals only when processing a signal.)

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.

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

What is your call on this?

Thanks,
Giuseppe

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.