Re: g_assert() semantics is changed without announce

["Havoc Pennington" <hp pobox com>]

Hi,

On Thu, Sep 25, 2008 at 1:06 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> The important part of the assert semantics are: if the assertion
> fails, the program aborts.
>
> If you are using assertions in a way that make it important where or
> how the message is reported, I suggest that you are using it wrong...

I leave assertions enabled in my code (they aren't --disable-checks)
so I get a decent message instead of a segfault.

The usual reason to replace g_log is that you have some canonical
place you want to dump a record of what your app is doing / did. The
text of an assertion failure is a natural thing to have there.

Using assertions in unit tests is a new innovation and *not* the
historical purpose of them, since there wasn't even a unit test
framework. It is totally legitimate to leave assertions in production
code and want them in your app log facility.

Now, in real life, most apps end up having to somehow get stderr in
their logs anyway, because not everything uses GLib. But, g_log does
let you do things in a nicer way, e.g. printing a prefix on the
messages, while stderr does not.

And the fact that we're hacking around non-GLib stuff doesn't really
mean we should require hacking around GLib itself to get everything in
the logs.

The ideal rule imo: glib should not write to stderr in a
non-redirectable way, inside an app. In clearly test-only code, stderr
could be fine. But apps should be able to send all output (including -
especially including - bugs) to a log file or other custom location.

Basically setting a default log handler should kill off stderr,
period, for glib-based libraries.

Havoc