`<format>`: Should we verify character arrays being null-terminated when creating `basic_format_arg`?

[frederick-vs-ja]

There're Preconditions specified in [format.arg]/5 for constructing a basic_format_arg:

Preconditions: If decay_t<T> is char_type* or const char_type*, static_cast<const char_type*>(v) points to a NTCTS ([defns.ntcts]).

And character arrays are decayed per [format.arg]/6.9:

otherwise, if decay_t<TD> is char_type* or const char_type*, initializes value with static_cast<const char_type*>(v);

It seems that we can check the content of the array (of known bound) in this internal factory function.

STL/stl/inc/__msvc_ranges_tuple_formatter.hpp

Lines 277 to 293 in 44a276f

	// Function template _Make_from mirrors the exposition-only single-argument constructor template of
	// basic_format_arg (N4950 [format.arg]).
	template <_Formattable_with<_Context> _Ty>
	_NODISCARD static basic_format_arg _Make_from(_Ty& _Val) noexcept {
	using _Erased_type = _Format_arg_traits<_Context>::template _Storage_type<_Ty>;
	if constexpr (is_same_v<remove_const_t<_Ty>, char> && is_same_v<_CharType, wchar_t>) {
	return basic_format_arg(static_cast<_Erased_type>(static_cast<unsigned char>(_Val)));
	}
	#if !_HAS_CXX23
	else if constexpr (is_same_v<_Erased_type, basic_string_view<_CharType>>) {
	return basic_format_arg(_Erased_type{_Val.data(), _Val.size()});
	}
	#endif // !_HAS_CXX23
	else {
	return basic_format_arg(static_cast<_Erased_type>(_Val));
	}
	}

Should we verify that the array is null-terminated? Note that the checking is not O(1) but still seems cheap in formatting to me.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and we agree that this is worth doing.

We believe that this check can be performed without paying two linear-time costs. Here, we know we're dealing with char or wchar_t arrays, so there's no question of wacky char_traits. We can use strnlen/wcsnlen to get the length of the hopefully-null-terminated string but clamped to the array size. As the documentation explains, if these functions return the array size, that's impossible for a properly null-terminated string, so that's the error case that we can then precondition-check. As @CaseyCarter notes, we don't expect huge array arguments, and the additional expense should be low, so let's try an always-enabled check that uses _STL_VERIFY.

[frederick-vs-ja]

If we decide to scan the array, it seems more sensible to store a basic_string_view instead of const _CharT*. Currently libc++ (uncoditionally) does so, although the array is not scanned and hence the stored length is sometimes wrong (which is being fixed by LLVM-116571).