Well thanks :-) (as I discover it now, there seems to be only a balance of -1, I guess it was more severe when you saw it). What's funny is that the day before, I got like 10 upvotes for saying how, when I occasionally, quickly browsed a few short patches for Linux kernel drivers, I found rather obvious mistakes which should have been caught by reviewers, if they did there work properly. Oh well... :-)

To sum up, I'd say I quickly looked at 2 of the most common sources of mistakes:

- off-by-one errors: here, in the sub-species which concern how the NUL terminator is counted (or not counted), whether it is by the code itself, or by calling standard functions which behave differently in that respect (sometimes for good reasons, sometimes not, but in all cases one should be careful and check their spec twice);

- error management: what happens, what could we get as a result when an input is not in a typical range, how can we deal with it; standard functions are not especially regular in that respect, one should check that aspect of their spec too, for it can be unintuitive (as in the case of strftime() here).

Then I explained how the consequences were not serious in that case. In a well commented code, I'd expect a small comment to explain why this check is not done, why one can emit that without much care, and so on. Otherwise, one cannot know if it works by design or by chance; also if future modifications should happen with those pieces of code, problems could arise.

Emitting a NUL character to a (pseudo) terminal is not serious. In the worst case it could mess the display for 1 or 2 lines before it recovers, but generally it won't even have a visible effect, the terminal will simply ignore it.

However, if that gets written or redirected to a file (here, a log file for example), then the NUL character is quite present. Since a civilised text file oughtn't to contain a NUL character, a program which expects well-formed text files may not be ready to handle it properly. For example, reading such a file with the standard C function fgets() or similar will land you in a world of troubles. fgets() only stops when it encounters a newline character, so the NUL character will be included inside the string returned by fgets() (here, coming right after a newline, it would be at the start of the next line); but when you'll ask for the string length, it will be 0 (NUL being the first character), and printing the string will be the same as printing an empty string. Basically, you have lost the line content.

So it is better to be as correct as possible from the start. It is also often easier than thinking exhaustively of all possible implications.