Actually there is nothing wrong with the current snprintf usage. When null terminator does not fit, snprintf still fills other characters, and return the same result. The null terminator will be set anyway by string::resize_and_overwrite

snprintf always null-terminates. So when we ask snprintf to format an 8-character string into an 8-character array, we get back seven characters and a null terminator, and it returns 8. The resulting string has an "internal" \0 where we actually wanted the last character of our output to be.

TLDR: If we want to use snprintf for formatting, we have to either allocate one extra byte of space or we have to assume that the external code allocates that extra byte for us and increase the value we pass to snprintf by one. The latter is guaranteed safe by [string.capacity]/7.3 which says that [p, p + n] is a valid range (note the fully-closed range) when resize_and_overwrite calls op(p, n).

After thinking about this, Casey's suggested pattern appears to be best. I thought about avoiding the - 1 followed by the + 1 but that's really just embedding the implicit count of the null terminator so it doesn't really simplify things.

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.