Re: Couple of items

[Tim Janik <timj gtk org>]

On Wed, 27 Mar 2002, Owen Taylor wrote:

> 
> [ 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.

i don't understand this part, libraries should _never_ make use of g_print()
or g_printerr(), they are supposed to use the logging facilities.

>    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.

you can use escape codes to switch character sets, e.g. to get IBM style
|
+- corners, --- lines, double lines, etc...
|

> 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.

yep, the statement here is actually that g_print() and g_printerr() are
the GLib versions of fprintf(stdout,) and fprintf(stderr,). making them
do conversions is basically bad API breakage (since we have these functions
for a long time now).

> 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); ]

i'm not sure you got my note correctly. the functions in question are only
g_print() and g_printerr(). everything that goes through g_logv() (i.e. warnings,
errors, etc...) is converted to the current locale. note that the conversion
occours in the g_log default handler though, which means, if you install
a user handler for a specific log domain to catch log messages, you're still
passed the original unconverted UTF-8 string.

> 
> Regards,
>                                         Oweb
> 
> 

---
ciaoTJ