To everyone who has the "contracts can inject new UB in observe mode"
concern: This is a fine concern. I encourage you to keep raising it and we
will hear it again in Kona. Summarizing the "new UB" concern for everyone,
it's that in cases like the following, the second line might introduce "new"
UB if the body of the function doesn't otherwise dereference p:

 

               contract_assert (p != nullptr);

               contract_assert (p->foo());

 

I have just one request please, to try to reduce a lot of repetitive email
list traffic (and Kona discussion time) about this: PLEASE, whenever you
mention this concern, could you include a brief acknowledgment like 'yes,
this new-UB problem is existing practice using any assertion library with a
check-and-continue mode'? [*]

 

Of course you're still fully free to add "but that's bad and we still don't
want such a mode in the standard!" That's totally fine. [**]

 

I think including that brief acknowledgment could reduce a lot of the
repetitive replies where people seem to feel obliged to repetitively keep
pointing this out (often at great length) each time the "new UB" issue is
mentioned.

 

It's up to you of course, but thanks for considering this request.

 

Herb

 

 

[*] Such as BOOST_ASSERT when used with a violation handler that continues
(thanks to Peter Dimov, the maintainer, for confirming!), more generally any
assertion library that supports a violation handler that returns,
Boost.Test's check-and-continue macros (BOOST_TEST, BOOST_WARN,
BOOST_CHECK), and other similar libraries.

 

I did a quick search on GitHub using the regexes

               /BOOST_ASSERT.*!=\snullptr/
<https://github.com/search?q=%2FBOOST_ASSERT.*%21%3D%5Csnullptr%2F&type=code
>

and

               /BOOST_CHECK.*!=\snullptr/
<https://github.com/search?q=%2FBOOST_CHECK.*%21%3D%5Csnullptr%2F&type=code>


For each one, the results contained many examples of "assert p not null;
assert p->something;" as separate assertions, with check-and-continue
semantics. Here's a quick example hit for each query, both in the first
half-dozen search results:

 

* BOOST_ASSERT example: Here's one in Mat
<https://github.com/matus-chochlik/oglplu2/blob/abf1e28d9bcd0d2348121e8640d9
611a94112a83/source/enums/make_enum.py#L646-L650> ú¹ Chochlík's Python C++
code generator.

 

* BOOST_CHECK example: Here's one in an LLVM unit test
<https://github.com/runtimeverification/llvm-backend/blob/618f530031870d6e8a
74633b122d46afb5d7ad8e/unittests/runtime-io/io.cpp#L676-L681> - and the
same function has three more examples. another null example, and two
examples that (if I'm reading them right) are "assert string is
null-terminated; assert strlen(string) == something;" which would be
equivalently UB.

 

[**] It would really help to know from Boost.Assert/Boost.Test maintainers,
and similar assertion library maintainers, if such existing examples have
generated user complaints and bug reports about the second assertion's UB?
That would be a good data point in favor of not allowing such examples to be
written using the standardized facility.