Re: printing 0xbeef wchar_t on x86-windows...

[Joel Brobecker <brobecker@adacore.com>]

Thanks for the review, Tom.

> generic_emit_char should be assuming that the character is in the target
> wide charset, not in the target charset.  That is, "show
> target-wide-charset".

> If the 'encoding' argument to generic_emit_char is "CP1252" then I think
> something went wrong earlier.

I will double-check what is exactly going on. I only very recently
discovered the target-wide-charset setting (and will post a patch
for AIX soon), so I probably still only have a partial picture.

> Joel>   * Before actually printing the buffer, generic_emit_char converts
> Joel>     the string from the intermediate encoding into the host encoding,
> Joel>     which is "CP1252". The converstion routine now finds that,
> Joel>     although the multi-bypte sequence is printable, it isn't valid
> Joel>     in the target encoding (iconv returns EILSEQ), and thus
> 
> Must be the host encoding here, not the target encoding?

Yes - poor (overloaded) choice of terms in this case. I shoud probably
have used "destination"...

> And, this call to convert_between_encodings is converting from the
> intermediate charset to the host charset.  So, I think this should be
> sizeof (gdb_wchar_t).

I keep getting confused over these...

> Before putting something like that in, though, I would like to look at
> Keith's pending patch that reworks this code.  Maybe he already fixed
> the bug.

OK. I couldn't find the patch in question, so I couldn't test it.

> Also, I think this should have a regression test.

We actually already have one (see wchar.exp).

-- 
Joel