search: Print dot in results for nonprintable chars

[kazarmy]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository.
• I made sure to follow the project's coding style.
• I've documented every RZ_API function and struct this PR changes.
• I've added tests that prove my changes are effective (required for changes to RZ_API).
• I've updated the Rizin book with the relevant information (if needed). Update "/ lib" invocation on /bin/ls book#138

Detailed description

#4762 hasn't landed yet (hopefully it'll be merged soon) so this pr improves slightly the current search results by using '.' for nonprintable chars instead of ignoring them, so that some additional information is provided in the results, and words don't run together.

Test plan

The change makes sense. All builds are green.

Closing issues

...

[notxvilka]

Nice improvement!

[Rot127]

Mh, idk. The behavior doesn't make sense to me. If the user searches for "test" but gets as a result ........test....... it is not a match. Doesn't it? It would be a match for .+test.+ (assuming . also includes non-printable characters).

I think it is better to wait for the refactor merge and edit the process_one_string() function (used in #4762 to discover strings) and escapes the non-printable chars their. It doesn't handle Unicode non-printables as well, but this is not too difficult to fix. Also we should give the option to define which non-printables should be included in a string and which are not (mark the end of a string).

[kazarmy]

Mh, idk. The behavior doesn't make sense to me. If the user searches for "test" but gets as a result ........test....... it is not a match. Doesn't it?

If console colors are enabled (which is usually the case), then "test" will be highlighted i.e. ........test........ Even if colors are not enabled, the user does know what is being searched and the searched string will usually be somewhere in the middle.

I think it is better to wait for the refactor merge...

There's no harm merging it now (from my perspective, you can choose to ignore this pr in the refactor and I will probably, eventually fix any regressions, time permitting, though they should be easy fixes now that I have an idea of what the code should look like), and it's certainly better than what is currently being used, e.g. see this before/after below of a search on an actual binary:

Before	After

[Rot127]

Valid point, go ahead then.

[kazarmy]

Thanks! ☺️

[kazarmy]

It would be a match for .+test.+ (assuming . also includes non-printable characters).

Hmm it would be good if an actual . can be differentiated from a . that is a non-printable character.