The constructor taking a const CharT (&)[M] copied M - 1 characters
verbatim via assign(arr, M - 1), preserving any embedded NULs in the
input. This would violate the type's documented "no embedded NULs"
invariant.
const char arr[] = { '1', '2', '\0', '4', '5', '\0' };
static_cstring<5> s(arr);
// data_ holds {'1','2','\0','4','5','\0'} --- embedded NUL stored
Delegate to assign(arr) instead, which uses traits::length() to
determine the size. This matches the behavior of the other
CharT-accepting entry points (assign(const CharT*), the const CharT*
constructor) and makes the invariant self-enforcing at construction.
Note: In practice, this is a bug that would never surface, because the
array constructor is never chosen for static_cstring<N> s(arr)---the
pointer constructor always wins---but the array constructor is needed
for CTAD (deduction guide), so it better be correct.
This also means the test we added is, at the moment, superfluous.
compare(const CharT* s) constructed a temporary basic_static_cstring<N>
from s and delegated to the class-type overload. The constructor throws
std::length_error when traits::length(s) > N, and because compare() is
noexcept, the throw led to std::terminate():
static_cstring<3> s("abc");
s.compare("abcd"); // terminate() via noexcept throw
The free operator==() / operator!=() overloads for const CharT*, which
delegate to compare(), had the same flaw.
The defaulted operators had the wrong semantics, as they compared the
entire data_ buffer. The bug showed up when shrinking:
static_cstring<10> s("hello");
s.assign("hi", 2); // data_[3..4] still "lo"
static_cstring<10> fresh("hi");
assert(s == fresh); // FAILED
This introduces an alternative to basic_static_string designed for use
in POD types: Trivially copyable, having a sizeof == N + 1, with no
embedded NULs.
Placed in example/ to gather user feedback before committing to a public
API. See issue #23.
Gennaro Prota