Re: Couple of items

[Owen Taylor <otaylor redhat com>]

[ Cc'ing gtk-devel-list ]

Tim Janik <timj gtk org> writes:

> note that we're not converting g_print() and g_printerr() messages from UTF-8
> now. for one, this badly breaks valid valid uses of those functions, e.g.
> - putting out escape codes to switch charset and then using characters
>   beyond 127
> - any application which prints out binary data through these functions
> 
> also, g_print() and g_printerr() should behave like fprintf(stdout,) and
> fprintf(stderr,) as they aren't much more than API wrappers with hooks
> to catch the output so they shouldn't do any conversion that fprintf()
> wouldn't either. (i'd recommend adding print variants which do the conversion
> in a future version though).

I strongly disagree with this:

 * We use them in various places throughout the GTK+ library stack with
   UTF-8 arguments.

   We are telling people to use UTF-8 as their internal encoding when
   programing with GLib-2.0 and GTK+-2.0. If you are doing this, then
   then g_printerr() in particular becomes entirely useless if it
   doesn't convert character sets.

 * You can't properly trap these functions and redirect them to a GTK+ dialog if
   the input to them isn't in UTF-8.

 * The GLib release notes said:

     Similarly, the GLib error logging functions such as g_print(), g_warning(),
     g_error(), currently do not convert the strings they are passed from
     UTF-8 to the encoding of the locale, or check that the strings they
     are passed are valid UTF-8. They should, despite this, be assumed to take
     UTF-8 arguments.

Basically, I see no reason to use g_print() and g_printerr() instead
of stdio if they don't convert, becuase it breaks redirection and it
breaks the convenience.

As for your points about escape codes and binary data:

 * I don't really understand what you mean by escape codes. Printing out 
   characters not in your locale is not generally going to work.

 * People outputing binary data through g_print() is indeed a concern.

   I believe that this usage is not a correct usage; if you are outputing
   binary data.

    - You don't want it redirected
    - You want to have exact control of how things work, so you should
      use stdio or even direct fd access instead of GLib wrappers around them.

   I don't think there is a good answer here.

We've basically made conflicting statements on this subject:

 - [ An explicit one ] g_print*() is supposed to take UTF-8 strings.

 - [ An implicit one ] g_print*() used to pass things through literally.

We are going to have a chance of hurting some people over either way.
I'd really prefer to take the route that leaves us with useful 
g_print() and g_printerr() functions rather than useless g_print()
and g_printerr() functison.

Maybe we should hold off on this patch until after 2.0.1, so we can get some
confirmation that people aren't using g_print() for binary data, but that
worries me too. Every day we have a GTK+ out there with buggy g_log() functions
is a day where someone may write:

 str = g_utf8_to_locale (message);
 g_warning ("%s", str);

[ Or, mostly likely, get it wrong and write g_warning (str); ]

Regards,
                                        Oweb