Clean up OSL_ASSERT, DBG_ASSERT, etc.

[Stephan Bergmann]

On 01/16/2015 04:42 PM, Ashod Nakashian wrote:
> On Fri, Jan 16, 2015 at 9:14 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
>> What do you mean with "what to expect" here?
>
> As in "would a piece of code abort or just log?" Of course we can find
> out what individual macros do, but the code mixes logging and aborting
> asserts, which means if it doesn't abort doesn't mean that no
> invariant is violated.

This should become a non-issue when 
<https://bugs.freedesktop.org/show_bug.cgi?id=43157> "Clean up 
OSL_ASSERT, DBG_ASSERT, etc." is fixed.

> But you don't comment on the more important points!
[...]
> I know some significant work has already been done in cleaning up
> assertions. This in no way invalidates them at all.
> In fact, changing assert to LO_ASSERT is trivial. The effort to
> convert the OSL_ and DBG_ ones remains the same (with or without the
> above proposal).
>
> However, LO_ASSERT will support the above advantages and give full
> control over assertions in the project. The cost is very low (surely
> searching and replacing assert with LO_ASSERT is not a high cost). The
> variants will allow more fine-grained control and will make the
> behavior more homogeneous.
>
> I hope you agree that this is an improvement over, and not a
> competition with, the current effort to replace OSL_ and DBG_ versions
> with assert.

Over the years, we've seen lots of attempts come and go to devise 
sophisticated assertion/logging/debugging mechanisms, none of which lead 
to a clean, consistent code base.  The current approach (assert, 
SAL_WARN, SAL_INFO) is deliberately simplistic.

I would not say that you are not raising relevant points, but at this 
point I would rather like to see fdo#43157 getting fixed, and not 
introduce yet another approach into the zoo.