Messages in this thread | | | From | Keith Owens <> | Subject | Re: [patch] kernel events layer | Date | Sat, 24 Jul 2004 14:42:41 +1000 |
| |
On Fri, 23 Jul 2004 22:47:06 -0400, Robert Love <rml@ximian.com> wrote: >On Sat, 2004-07-24 at 00:32 +0300, Dan Aloni wrote: > >> IMHO you either should not assume anything about the length of the object >> string, _or_ do the complete safe string assembly e.g: >> >> len += snprintf(buffer, PAGE_SIZE, "From: %s\nSignal: %s\n", >> object, signal); >> > >Fair enough. I guess what we want, exactly, is: > > len = snprintf(buffer, PAGE_SIZE, "From: %s\n", object); > len += snprintf(&buffer[len], PAGE_SIZE - len "Signal: %s\n", signal); > >I will add that to the next revision.
man snprintf
"If the output was truncated due to this limit then the return value is the number of characters (not including the trailing '\0') which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated".
Never use the return value from snprintf to work out the next buffer position, it is not reliable when the data is truncated. The example above uses a second call to snprintf which will generate a warning for truncated data and fail safe, but not all code is that trustworthy. I always use strlen to get the real buffer length.
snprintf(buffer, PAGE_SIZE, "From: %s\n", object); len = strlen(buffer); snprintf(buffer+len, PAGE_SIZE - len, "Signal: %s\n", signal);
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |