chiark / gitweb /
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)
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

diff --git a/log.c b/log.c
index 4f1b651..9cd0572 100644 (file)
--- a/log.c
+++ b/log.c
@@ -38,6 +38,8 @@ static void vMessage(uint32_t class, const char *message, va_list args)
        bp=strlen(buff);
        assert(bp < MESSAGE_BUFLEN);
        vsnprintf(buff+bp,MESSAGE_BUFLEN-bp,message,args);
+       buff[sizeof(buff)-2] = '\n';
+       buff[sizeof(buff)-1] = '\0';
        /* Each line is sent separately */
        while ((nlp=strchr(buff,'\n'))) {
            *nlp=0;