[hdijkema]

Characters need to be in the ascii range, otherwise invalid UTF-8 data can (and is) written.

So anything outside the 32-126 range is output as hexadecimal number.

[AlbertShown]

I did those minor changes:

• Bring back the "%c" instead of 0x%02X when byte is 0x00. That's because we want to see logs like this arg1¤arg2¤arg3 instead of arg10xCFarg20xCFarg3
• Moving your register unsigned char c up 👍

[hdijkema]

Hi AlbertShown,

The problem with 0xCF in a UTF-8 context is that it is a marker for a multi byte sequence.
So when an integrating language defaults to UTF-8, there will be interpretation, which can lead to exceptions.
Sorry for this side effect of the logging system.

For the sake of documentation:

In UTF-8, multi-byte sequences are introduced by leading bytes that start with a specific pattern
of ones followed by a zero, indicating the number of continuation bytes. Bytes that are part of
a multi-byte sequence but are not the first byte are called continuation bytes, and they
always start with the pattern 10xxxxxx.

Leading bytes (head bytes):

• 2-byte sequence: 110xxxxx
• 3-byte sequence: 1110xxxx
• 4-byte sequence: 11110xxx

So CF indicates a 2-byte sequence.

It might be better to do something else, e.g. a ~ (126) or a tab (9).

[AlbertShown]

I see, I agree with you. I suggest we simply remove 0xCF so it will be printed as hex.

[AlbertShown]

Fixed in 3093057.