Colors in error messages

[Jakub Wilk]

Hi!

With my nitpicker hat on, I'd like to protest ;-) against AFL's
inconsistent use of colors in error messages. For example, here the
colon after "OS message" has the default color, but all the other colons
in the same column are red:
https://i.imgur.com/2evLlVZ.png

Also, I think it looks better when there's no space before a colon.
Wikipedia seems to agree with me:
https://en.wikipedia.org/wiki/Colon_%28punctuation%29#Spacing

--
Jakub Wilk

[Michal Zalewski]

> With my nitpicker hat on, I'd like to protest ;-) against AFL's inconsistent
> use of colors in error messages. For example, here the colon after "OS
> message" has the default color, but all the other colons in the same column
> are red:
> https://i.imgur.com/2evLlVZ.png

Scandalous!

I am actually acutely aware of this atrocity, but was lazy in using
popen, which doesn't give us sufficiently fine-grained control over
this. Will try to fix at some point ;-)

/mz

[Michal Zalewski]

> I am actually acutely aware of this atrocity, but was lazy in using
> popen

...err, perror()

[Jakub Wilk]

* Michal Zalewski <lca...@gmail.com>, 2015-01-20, 14:07:

>>With my nitpicker hat on, I'd like to protest ;-) against AFL's
>>inconsistent use of colors in error messages. For example, here the
>>colon after "OS message" has the default color, but all the other
>>colons in the same column are red:
>>https://i.imgur.com/2evLlVZ.png
>
>Scandalous!
>
>I am actually acutely aware of this atrocity, but was lazy in using

>perror, which doesn't give us sufficiently fine-grained control over
>this.

Well, you probably shouldn't mix perror() with SAYF() anyway, because
perror always prints to stderr and SAYF could print to stdout.

SAYF(..., strerror(errno)) should do the trick and let you paint the
colons any color you like. :-)


Speaking of colors, a Debian user complained[0] that error messages are
unreadable on white-background terminals. This should be easily fixable
by setting defining cBRI as "\x1b[0;1m".

But then, the status screen is also hardly readable on white-background
terminals, which is a know problem. Why can't afl-fuzz just set
background color to black ("\x1b[40m")?


[0] https://bugs.debian.org/776624

--
Jakub Wilk

[Michal Zalewski]

> But then, the status screen is also hardly readable on white-background
> terminals, which is a know problem. Why can't afl-fuzz just set background
> color to black ("\x1b[40m")?

It's definitely doable for the main UI. The problem are all the
initial status messages / errors / warnings when we haven't yet
cleared the screen - changing background at that point will look ugly.
I... sort of need to do something with it, but didn't have any
brilliant ideas so far. I think the colors are fairly useful. Too bad
that there is no way to query the terminal to see if it's in reverse
or normal video :-/

/mz

[Pádraig Brady]

For starup messages, you could use something more abstract like
"standout mode". For example:

tput smso; echo warning; tput sgr0; echo normal

Also with 256 colors you should be able to pick colors
more compat with either light or dark terminals.
256 or generally available and auto enabled on OS X
and Fedora at least. More details at:
http://www.pixelbeat.org/docs/terminal_colours/#256

cheers,
Pádraig.

[Jakub Wilk]

>On 01/02/15 00:16, Michal Zalewski wrote:
>>>But then, the status screen is also hardly readable on
>>>white-background terminals, which is a know problem. Why can't
>>>afl-fuzz just set background color to black ("\x1b[40m")?
>>It's definitely doable for the main UI. The problem are all the
>>initial status messages / errors / warnings when we haven't yet
>>cleared the screen - changing background at that point will look ugly.

If you avoid setting gray or white foreground colors, and instead use
the default color, those initial messages should look good enough. Then
you could set the background color only for the main UI.

>>I... sort of need to do something with it, but didn't have any
>>brilliant ideas so far. I think the colors are fairly useful. Too bad
>>that there is no way to query the terminal to see if it's in reverse
>>or normal video :-/

getenv("AFL_WHITE_BG") maybe? :-)

* Pádraig Brady <P...@draigBrady.com>, 2015-02-01, 02:10:

>Also with 256 colors you should be able to pick colors more compat with
>either light or dark terminals. 256 or generally available and auto
>enabled on OS X and Fedora at least. More details at:
>http://www.pixelbeat.org/docs/terminal_colours/#256

Linux console learned about these sequences only recently. Older
versions (at least 3.2, which I'm currently stuck with) seriously
misinterpret them. :-(

--
Jakub Wilk

[Michal Zalewski]

> If you avoid setting gray or white foreground colors, and instead use the
> default color, those initial messages should look good enough. Then you
> could set the background color only for the main UI.

I think this is kinda hit-and-miss. For example, if we change cGRA and cBRI to:

# define cGRA "\x1b[2m"
# define cBRI "\x1b[1m"

...then cBRI is rendered as some horrific underlined text in PuTTY,
and cGRA has no effect on the OpenBSD console.

:-/

/mz