I'm surprised to find out that g_log() sometimes writes to stdout...

Anyway, looking at the code it would appear that the only time this value is used is to pass as the first argument to this function:

static void
write_string (int          fd,
              const gchar *string)
{
  write (fd, string, strlen (string));
}


So we could probably just use the FILE* directly and use fputs() instead.

One problem with this approach is that mklevel_prefix is called from the recursive log handler which tries very hard not to call anything 'fancy' that may allocate memory or other system resources.  This may be part of the reason that we try to use write() here instead of stdio.  Is it possible that calling fileno() could also do some fancy internal stuff on Windows (like allocating the fd if it does not already exist)?  In any case, I wouldn't be surprised if it is at least taking a lock...

(In reply to comment #1)
> Is it possible that calling
> fileno() could also do some fancy internal stuff on Windows (like allocating
> the fd if it does not already exist)?

No idea, fileno() is part of the Win32 API so we don't know what happens internally. At http://msdn.microsoft.com/en-us/library/zs6wbdhx%28v=vs.80%29.aspx you can find the documentation about this API but it doesn't tell us anything about locks or memory allocations.

(In reply to comment #1)
> So we could probably just use the FILE* directly and use fputs() instead.

though as just discussed on the mailing list, there are other places in glib where we make this assumption too

Created attachment 301215 [details] [review]
Change message system to use fputs instead of write

Created attachment 301216 [details] [review]
Change message system to use fputs instead of write

Windows might use a different fd number for stdout or stderr
so instead of using fd numbers change it to use the FILE directly.

Created attachment 301217 [details] [review]
Change message system to use fputs instead of write

By default g_log_default_handler always assumes that stdout
and stderr are file descriptors 1 and 2. On Win32 this isn't
always the case as the win32 API functions AttachConsole and
freopen can be used to dynamically attach GUI applications to
a console and the file descriptors of stderr and stdout will
become different than 1 and 2.

Fix it by using fputs with the FILE directly instead of
using the file descriptors.

Review of attachment 301217 [details] [review]:

Looks fine.

Thanks for the good commit message.

Thanks for the review. Pushed as: https://git.gnome.org/browse/glib/commit/?id=fb9df27776b116d9e8552c0b7b3109245a9c0d26