Discussion point: do we want to go for UTF-8 by default?

Hi! We only accept PRs to dev so I changed the destination for you.
Thanks for this, this looks valuable :)
Let me test on a few terminals tomorrow how it behaves if this can be the default

Hi! We only accept PRs to dev so I changed the destination for you. Thanks for this, this looks valuable :) Let me test on a few terminals tomorrow how it behaves if this can be the default

Ah, my bad. Thanks for changing the destination.

sorry for the long wait, I have a lot on my plate ...
looks good to me and I am for having this the default, so could you please make the following changes

• change UTF to NO_UTF in the GNUmakefile (and logic accordingly).
• add in src/afl-fuzz.c usage() an ifdef line that prints Compiled (not) with UTF8 suppport (as are other similar options).

thank you!

No worries, should be good to go.

@andreafioraldi, I do not develop for Android, nor use adb. I see that you introduced the disabling of fancy_boxes for Android compilation. Does UTF-8 rendering work in adb as well?

i.e. can we remove this compilation exception for Android?

Andrea is on vacation currently. via adb the rendering is on the host so I do not see why this would break this. output on android itself (app, serial, ...) - but android's default is utf8 too.
so I' d say remove the android restriction and if someone complains it can still be reverted (or user sets NO_UTF8).

Sure, thing. Feel free to merge it in its current state.

@vanhauser-thc, no clue why the test on Ubuntu-22.04 fails. Do you have any thoughts?

https://github.com/AFLplusplus/qemuafl/blob/a1321713c7502c152dd7527555e0f8a800d55225/qemuafl/imported/config.h#L123 should probably be updated as well

As well as https://github.com/AFLplusplus/unicornafl/blob/7e4e68ae5b93ee02bccd1a47b0a05671c50f3a54/include/config.h#L123

The fail is a change in gcc, not important.
Thank you!