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

Joel Brobecker
2012-10-16T22:43:57Z

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