log: Print truncated messages
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Wed, 13 Jun 2012 23:37:16 +0000 (00:37 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Thu, 12 Jul 2012 19:02:20 +0000 (20:02 +0100)
commitb7164ab60bf28a93fc02bb65b784134fcbbc41c5
tree8c630ccaf3443cf9811587c6f6bfbc063f25f730
parentba72e2bf5e1a1cedc74f7de35e29cce7a0f4fca1
log: Print truncated messages

If a message doesn't survive the vsnprintf in vMessage untruncated,
the result may be that its newline is lost.  After that, buff will
never manage to gain a newline and all further messages will be
discarded.

Fix this by always putting "\n\0" at the end of buff.  That way a
truncated message is printed and the buffer will be cleared out for
the next call.

This does mean that sometimes a message which is just slightly shorter
than the buffer will produce a spurious empty message sent to the
syslog.  However, the whole logging approach here will inevitably
occasionally insert spurious newlines, if only to split up long
messages; long messages may also be truncated.  The bad effect of the
change in this patch is simply to make the length at which
infelicities appear very slightly shorter.  The good effect is that it
turns a very nasty failure mode into a benign one.

So I think it is reasonable to err on the side of code which clearly
cannot go wrong in a bad way.  Other approaches which make the
infelicity threshold a couple of characters longer, or which slightly
reduce the different kinds of infelicity, are much more complicated
and therefore more likely to have bugs.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
log.c