On Mon, 1 May 2023 at 08:06, Kefu Chai via Libstdc++ <libstdc++@gcc.gnu.org>
wrote:

> This always sets _M_string_length in the constructor specialized for
> range of input_iterator, for the cases like istringstream.
>
> We copy from source range to the local buffer, and then reallocate
> to larger one if necessary, when disposing the old buffer. And the
> old buffer could be provisioned by the local buffer or an allocated
> buffer. _M_is_local() is used to tell if the buffer is the local one
> or not. In addition to comparing the buffer address with the local buffer,
> this function also performs the sanity check if _M_string_length is
> greater than _S_local_capacity, if the check fails
> __builtin_unreachable() is called. But we failed to set _M_string_length
> in this constructor is specialized for std::input_iterator. So,
> if UBSan is enabled when compiling the source, there are chances that
> the uninitialized data in _M_string_length is greater than
> _S_local_capacity, and the application aborts a runtime error or
> exception emitted by the UBSan.
>
> In this change, to avoid the false alarm, _M_string_length is
> updated with the length of number of bytes copied to local buffer, so
> that _M_is_local() is able to check based on the correct length.
>
> This issue only surfaces when constructing a string with a range of
> input_iterator, and the uninitialized _M_string_length is greater than
> _S_local_capacity, i.e., 15.
>
> libstdc++-v3/ChangeLog:
>
>         * include/bits/basic_string.tcc (_M_construct): Set
>         _M_string_length before calling _M_dispose().
>
> Signed-off-by: Kefu Chai <kefu.chai@scylladb.com>
> ---
>  libstdc++-v3/include/bits/basic_string.tcc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libstdc++-v3/include/bits/basic_string.tcc
> b/libstdc++-v3/include/bits/basic_string.tcc
> index 99fdbeee5ad..ec2198ee20b 100644
> --- a/libstdc++-v3/include/bits/basic_string.tcc
> +++ b/libstdc++-v3/include/bits/basic_string.tcc
> @@ -177,6 +177,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>             __p[__len++] = *__beg;
>             ++__beg;
>           }
> +       _M_length(__len);
>
>         struct _Guard
>         {
> --
> 2.40.1
>

Thanks for finding the issue, and providing the patch.

N.B. patches for libstdc++ (like all GCC patches) need to be sent to the
gcc-patches list. For libstdc++ they should also be sent to the libstdc++
list (as you did) but they still need to be CC'd to gcc-patches.

I think I'd prefer to do it this way instead, just initializing to zero at
the start of the constructor. What do you think?

Init'ing to an immediate zero should always be cheap. For the
ForwardIterator case the initialization can probably be eliminated as a
dead store. For the InputIterator case it avoids the bug (it doesn't matter
that _M_string_length isn't correct when _M_is_local() checks it, only that
it's not uninitialized to a value greater than the local capacity).