Re: Couple of items [ logging ]

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Wed, 27 Mar 2002, Owen Taylor wrote:
> 
> > > g_message() goes to stderr, exactly because it should be used instead
> > > of g_printerr(), so that programs can catch messages of a certain
> > > library and the user knows what module produced the output.
> > 
> > OK, the old code was a little unclear on the issue, and I've been
> > confused on this for a while.
> 
> i don't find the old code particularly hard to read:
> 
> 	  fd = (log_level > G_LOG_LEVEL_MESSAGE) ? 1 : 2;
 
Well for comparisons on enums are always a little confusing. :-) 
Is a higher log level more or less serious?
 
> > In a some cases, the debug
> > spew includes text from widgets (UTF-8), strings marked for
> > translation (UTF-8), err->message strings from (UTF-8) or filenames
> > (UTF-8 unless you set G_BROKEN_FILENAMES).
> 
> btw, G_BROKEN_FILENAMES=1 doesn't have any real effect on my machine,
> the file selection still complains about filenames in latin1 (that's
> with LANG=C). i tend to think g_filename_to_utf8() should be somewhat
> more clever about its fallback.

What I'm thinking about doing is replacing/supplementing G_BROKEN_FILENAMES
with a FILENAME_ENCODING variable, so you would do:

 export FILENAME_ENCODING=ISO-8859-1

Not that I don't think you will have a lot of other problems if you want
to use ISO-8859-1 without properly telling the C library what your encoding
is. (GTK+-1.2 apps, for instance, aren't going to work properly if you
configure GTK+ with the faster/better --with-native-locale.)

If you don't want translations, you should generally be using en_US,
not C, or perhaps some more complicated variant, e.g:

  LANG=de_DE LC_COLLATE=C LC_NUMERIC=en_US LC_MESSAGES=en_US
 
> > So, approximate tallies, would be:
> >                                         No Convert             Convert
> > 
> >   Work properly                       |     1900        |      2550
> > --------------------------------------+-----------------+--------------------
> >   Sort of broken, but doesn't matter  |      500        |       30
> > --------------------------------------------------------+--------------------
> >   Broken                              |      70         |        1
> > 
> >   
> > (Where I'm pretty sure about the last line.)
> 
> ok, that looks promising, thanks for collecting some sample data here.

Great. :-) I'm glad we have agreement there.
 
> > > that had to be changed. though i don't think there's a point in reverting
> > > that part, other than to use this as a threat in order to push conversion
> > > for g_print() and g_printerr() without further discussion.
> > 
> > Basically, I see the gmessages.c changes being in three parts:
> > 
> >  - Cleanups and fixes. Big, and not critical. (It's certainly better
> >    code now, but there were not problems that people were running into
> >    with the old code.)
> 
> unless they triggered recursive warnings or warnings in the threading layer.
> that code is still potentially harmfull, though much less now. fixing it
> requires making gmem.c and g_thread_self() g_log()-free and adding the log
> depth to GThread.

I don't think that fixes the problem; g_thread_self() can still allocate, and
does the first time it is called from a thread.

Probably the best thing to do would be to allocate a key with 
g_private_new() in g_messages_init() and use g_private_get() directly... 
with pthreads, g_private_get() shouldn't cause allocation of memory, though
having a special private key for this use will use up on of a limited number
total number of thread-specific-data keys.

Regards,
                                        Owen