Re: [PATCH v2 09/18] Include \0 in printable wide characters

[Tom Tromey <tom@tromey.com>]

Tom> I think the idea behind this is that only a real \0 in the input will
Tom> really ever turn into a L'\0' in the wchar_t form.  It seems to me that
Tom> an L'\0' pretty much has to correspond exactly to a target \0, just
Tom> because C is pervasive and an encoding where stray \0 bytes can appear
Tom> would break everything.

I went for a short walk and, naturally, realized this is only half
right.

An L'\0' can come from a non-zero target encoding in the Java flavor of
UTF-8, which exists precisely to smuggle a wide '\0' through a
multi-byte encoding.

https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8

So while I still believe that a target '\0' will always map to a L'\0',
it's not the case that an L'\0' necessarily came from one such, with the
Java-style 0xc0 0x80 being a counter-example.

In this case it's not 100% clear what is the best thing to do.  Possibly
iconv will just give an encoding error, as that is an overlong sequence.
Anyway maybe the right thing to do is print \xc0\x80 or the like, to
make it clear that something unusual is going on.

Tom> That's most likely because you are trying this on Linux.  Linux uses
Tom> UTF-32 for wchar_t, and so there aren't target characters that can't be
Tom> converted to a single wchar_t

I now wonder if this is true as well, because you might see a "CESU-8"
encoding:

https://en.wikipedia.org/wiki/CESU-8

... where surrogate pairs are represented as two UTF-8 sequences.  This
could show up as a target program decision to use this encoding,
combined with using UTF-8 in gdb.  I didn't experiment to see what iconv
does for this sort of thing.

I'll look into a Rust-specific fix and just drop this patch.

Tom