`c4::to_csubstr` includes trailing NULs in the string if given an array

[CookiePLMonster]

The following minimal example produces a malformed YAML file - if I understand correctly, unprintable characters are forbidden from being emitted into the YAML file, but this example produces key names with embedded \0's:

ryml::Tree newTree;
ryml::NodeRef root = newTree.rootref();
root |= ryml::MAP;

char entryName[32] = "EntryName";
// Sanitize 'entryName' here...
c4::csubstr key = c4::to_csubstr(entryName);

root[key] << 1;

FILE* file = fopen("test.yml", "w");
if (file != nullptr)
{
	ryml::emit_yaml(newTree, file);
	fclose(file);
}

Output:

The issue seems to be related to the fact that the following overload of to_csubstr is used:

template<size_t N>
C4_ALWAYS_INLINE csubstr
to_csubstr(const char (&s)[N]) noexcept { csubstr ss(s, N-1); return ss; }

This overload determines the buffer length at compile time and should be reserved ONLY to string literals, and arrays should always be directed to a const char* overload that determines the string length on runtime. This is evident if I inspect the value of key in the debugger:

To verify, I removed the const char (&s)[N] overload locally, and that "fixes" this specific case.

[CookiePLMonster]

My recommendation would be to remove char (&s)][N] and const char (&s)]N] overloads from to_substr, to_csubstr and basic_string and use std::char_traits::length(s) internally, much like std::string and std::string_view do. This almost definitely will preserve the behaviour of getting the length of a string literal at compile time, and also allow the char arrays to work correctly.

[CookiePLMonster]

I fixed bugs caused by this behaviour by foregoing c4::to_csubstr in favour of c4::csubstr(name, strlen(name));:
PCSX2/pcsx2#13110