Your INTERMEDIATE_ENCODING patch for Solaris

Pierre Muller pierre.muller@ics-cnrs.unistra.fr
Thu Sep 16 22:31:00 GMT 2010



> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : Thursday, September 16, 2010 8:31 PM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: Your INTERMEDIATE_ENCODING patch for Solaris
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> Tom> Great.  Here is what I am checking in.
> 
> Pierre>   Nice, but I was wondering if the
> Pierre> check of libiconv version is still needed.
> Pierre>   Wasn't it suggested by me?
> 
> According to the comment, versions of libiconv before 0x10D do not
> support "wchar_t" as an argument to iconv_open.
> 
> I think you discovered this, but it is hard to remember.
  Yes, I wrote that in
http://sourceware.org/ml/gdb-patches/2010-08/msg00296.html
but I now fear that I made an error in my analysis at that time.
   Rereading my email lets me think that maybe
the Sparc did not link to GNU iconv library, but instead tried
to use the libc iconv functions.
   Troubles is that I lost access to that Sparc machine.
> Pierre>   I think that checking for the existence of
> Pierre> _LIBICONV_VERSION macro should be enough,
> Pierre> unless you are really sure that older versions
> Pierre> do not work.
> Pierre>   On systems that have an older GNU libiconv
> Pierre> version installed, this might disable the use of GNU libiconv
> Pierre> without a good reason.
> 
> I think it is better to fail safe:
> If this code is disabled, the user gets reduced functionality.
> If this code is erroneously enabled, users can't print strings at all.

  Would it be possible to test an old libiconv on some other platform?

Pierre



More information about the Gdb-patches mailing list