Re: Enable string_view assertions

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 15 March 2018 at 00:18, Jonathan Wakely wrote:
> On 14 March 2018 at 23:27, Jonathan Wakely wrote:
>> Here's one way to generalize this idea. We could potentially replace
>> most of the lightweight __glibcxx_assert checks with this, to get
>> zero-overhead static checking at compile-time whenever possible (even
>> in constexpr functions) and have optional run-time assertions for the
>> remaining cases.
>
> Thinking about this some more, we probably don't want to do this for
> most __glibcxx_assert uses, because it's probably rare that we can
> statically detect most errors in something like
> std::vector::operator[]. I doubt we would catch many bugs that way, as
> most bugs would involve non-constant indices and vectors that have
> changed size dynamically at run-time.
>
> It *might* be useful  in vector::front, vector::back, string::front,
> deque::front etc. to catch bugs where users do:
>
> std::string s;
> // ...
> someFunction(&s.front(), s.size());
>
> It seems most valuable in constexpr functions (where we definitely
> expect constant arguments in many cases) and where run-time arguments
> will typically be constants, like in the attached patch for atomic
> objects.

Those patches aren't quite right. It's OK to make compilation fail
when undefined behaviour is detected in a constant expression, but if
we detect it in other contexts (because optimization means all the
inputs are known at compile-time) we need to use
__attribute((__warning__(""))) not __error__. Those cases are only
undefined if the code is executed, so we can only warn and then fail
at run-time.