Re: g_assert() semantics is changed without announce

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Fri, Sep 26, 2008 at 10:53 AM, Tim Janik <timj imendio com> wrote:
> On Fri, 26 Sep 2008, Andrew Cowie wrote:
>
>> On Thu, 2008-09-25 at 13:06 -0400, Matthias Clasen 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
>>
>> In the Java bindings we trap the log messages that are raised by
>> assertions and propagate a (quite fatal) Java Exception instead. That
>> quite nicely terminates the program, but in a way that a) gives the
>> developer some idea of where things are wrong, and b) doesn't crash the
>> VM in the process. Crashing VMs are rather frowned upon.
>>
>> The fact that assert uses the existing log facility is lovely. Please
>> revert back to this!
>
> Thanks for the feedback and use case descriptions everyone, I can definitely
> see the point why people want to see g_assert() using g_log() be restored.
>
> Similar reasons do apply in the testing framework case though, e.g.
> assertion
> messages from test programs should be sent on to the gtester framework
> executavle for logging and should usually not pollute stderr.
>
> I'll investigate if we either:
> - Restore g_assert()s old logging behaviour unless g_test_init()
>  has been called; or
> - Restore g_assert()s old logging behaviour unconditionally and just
>  capture + redirect everything from g_log() to gtester after
>  g_test_init() has been called.
>
> I hope that should fix everyone's issues.

Any news?  Or issue was forgotten? :-(

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>