Re: [PATCH/WIP] C/C++ wchar_t/Unicode printing support

[Julian Brown <julian@codesourcery.com>]

Thanks for the quick reply!

On Thu, 15 Jan 2009 13:59:51 -0700
Tom Tromey <tromey@redhat.com> wrote:

> >>>>> "Julian" == Julian Brown <julian@codesourcery.com> writes:
> 
> Julian> 3. Types which are literally called "wchar_t" are assumed to
> Julian> be wide characters.
> 
> I did something similar -- my patch looks at TYPE_NAME to see if it is
> "wchar_t".  In C, this is a typedef, and so I needed the appended to
> make it work.  Without this patch, lookup_typename will find a
> "wchar_t" symbol whose type has a TYPE_NAME which is not "wchar_t".
> That seemed odd.  The patch changes the dwarf reader so that the
> wchar_t symbol points to a type whose name is "wchar_t".
> 
> I think the failing case here was "p L'a'", so I suppose it would not
> necessarily show up with your patch.

I don't think I'd run across that problem, no...

> Julian> $3 = (wchar_t *) 0x85c4 "Sch\x00f6ne Gr\x00fc\x00dfe"
> 
> It should probably print L"..." :-)

Yeah, true.

> Yeah.  Mine:
> 
> * Handles input and output of wide characters and strings, and also
>   the new C0X u"" and U"" syntax.
> * Adds "%ls" and "%lc" to the gdb printf.

Sounds good.

> * Handles all target character sets, in particular variable length
>   encodings are handled.

My patch is supposed to handle variable-length encodings for target
wide character set -- but that's not tested, so is probably broken :-)

> * Auto-selects the appropriate endianness for wide characters on the
>   target.

Cool.

> * Getting the list of character sets support by iconv is a pain.
>   Right now I just have a list of dubious provenance (read: iconv -l
> | sed).
> 
>   Perhaps we can invoke "iconv -l" at startup... eww.

I ran into this problem too. An earlier version of my patch had this,
in register_iconv_charsets():

  FILE *fh;
  /* Fixed buffers never caused anyone problems did they?  */
  char charset[200];
  int seen_a_charset = 0;
  struct charset *cs;

  fh = popen ("iconv -l", "r");

  if (!fh)
    return 1;

  while (! feof (fh))
    {
      int n = fscanf (fh, " %s/%*s/", &charset[0]);

      if (n != 1)
        break;

      seen_a_charset = 1;

      register_charset (simple_charset (xstrdup (charset), 1, NULL,
                        NULL, NULL, NULL));
    }

  pclose (fh);

  return !seen_a_charset;

...which isn't quite right, but can maybe be adapted into something
which is.

> Another difference is that I have the intermediate step go through the
> host wchar_t rather than UCS-4.  This is nice because it means we can
> use iswprint to decide if something is printable.  But, it may have
> limitations, I suppose, on a host where wchar_t is less capable.

I think that might break for recent win32, where wchar_t is UTF-16 (i.e.
more than one wide character may be needed for a given code point).

> Julian> OK to apply, or any comments?
> 
> If you wouldn't mind holding off, my patch is nearing completion.  It
> is feature complete, and at the moment I am writing test cases.

Sure, I don't mind holding off.

> I'm happy to send what I have now, if you want to see it.  Or it is
> all in the archer git repository on the tromey-archer-charset branch.
> 
> I've lifted stuff -- ideas and code -- from your patch, but the result
> is pretty different.  Perhaps we could discuss the areas where we made
> different decisions and try to plot the best route forward.

OK, I'll have a look, but I'm not sure if I'll have anything sensible to
say :-)

Cheers,

Julian