On 01/16/2015 04:42 PM, Ashod Nakashian wrote:
On Fri, Jan 16, 2015 at 9:14 AM, Stephan Bergmann <[email protected]> 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.
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
