This is true in general, that \0 being a part of the string should be treated as such, and ideally the printing could be fixed in the framework. But for this specific issue, the direct cause is an out-of-bounds read, because OP reads from inputstr[-1] what is UB and kind of voids pretty much any other reasoning. Even if the message was not cut off and embedded \0's were encoded and dispalyed by the framework, there is still no guarantee what it would actually be in the OP's case.

if someone made a pull request to snowhouse to encode strings better, they might just accept that and then it would apply to all cpp kata

if it's considered (past) the end of the string, then why is it included in the error output?

https://github.com/banditcpp/snowhouse/issues/40

https://github.com/banditcpp/snowhouse/blob/8db10c8114e520ed4ee05dea850d671b32af049c/include/snowhouse/stringize.h#L90C36-L90C36

Unfortunately, this is something what can happen in C++ and it's not easy to do anything aobut this. Your solution has a bug, and at some place it puts \0 into some of the pieces. Later, the failure message is build, the \0 gets in a middle of it, and when printed, everything beyond the zero character gets cut off.

In your example, your first chunk is "a\0", and when it is used as a part of the failure message, the message is not printed fully because the \0 is considered he end of the string.

I can see how it is a problem, but it is not a bug in the kata, and it's not something what can be fixed very easily. Unfortunately, some low-level languages are like that, and C and C++ are the most common offenders in this regard.