Re: Couple of items

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

The question is not warnings about programming errors, but warnings 
intended for the user. (Frequently about system configuration errors).
Some people use g_printerr() for such messages rather than g_warning(),
even for libraries.

Points in favor of using g_printerr() for this:

 * --g-fatal-warnings, and also the code that various apps use to 
   emulate this automatically make g_warning() fatal, and treat 
   them as indicating programming errors that need to be debugged.

 * Messages at a severity less than g_warning() [info,message,debug]
   go to stdout rather than stderr which makes them entirely useless,
   especially for libraries. (Libraries never should interfere with
   stdout.)

 * g_warning() is very noisy, especially if you are trying to construct
    multiline messages with multiple statements. (Especially annoying,
   IMO is that g_warning() puts \n\n after each message)

Points in favor of using g_log variants:

 * They can be more flexibly redirected. (But it's not really clear 
   to me why you want to redirect some warnings and not others.)

 * They print process name and pid.

[...] 

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

This is something that you'd only ever want to do if you were sure that
your output was going to a terminal. I'd argue that if you want that, you
shouldn't be using g_print(), g_printerr(), but probably open ("/dev/tty", ...)
 
> > 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).

But, since g_print() and g_printerr() have redirection facilities they
aren't equivalent to fprintf(stdout,) fprintf(stderr,). 

I'm not sure why we would have g_print() equivalents for entirely
standard functions.

If we don't make these functions convert, then there will be *no* way
to print a redirectable string without introducing a lossy conversion 
to the locale and back, and *no* convenient way of printing to stderr
at all that fit's with our model of internationalization.

 void
 my_printerr_utf8 (const char *format, ...)
 {
  va_list args;
  gchar *str, *str_utf8;
  GError *err = NULL;

  g_return_if_fail (format != NULL);
  
  va_start (args, format);
  string = g_strdup_vprintf (format, args);
  va_end (args);

  str_utf8 = g_utf8_to_locale (str, -1, NULL, NULL, &err);

  if (str_utf8)
    {
      fputs (str_utf8, err);
      g_free (str_utf8);
     }
  else
    {
      fprintf (stderr, "Can't convert output to the locale: %s\n", err->message);
      fputs (stderr, str);
      g_error_free (err);
    }

  g_free (str);
 }

Will have to be cut-and-paste into every application.

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

No, I understood what the situation is. What I'm saying is, is:

 - I'd like to make everything (g_log() and g_print*()) convert.

 - If we are worried about g_print() and binary streams, maybe we should
   put the entire patch in after we release 2.0.1 so people have some
   time to fool around with it before we release.

I don't want to make 2.0.1 convert encodings on some stuff, and 2.0.2 
convert encodings for more stuff.

Regards,
                                        Owen