lkml.org 
[lkml]   [2004]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] kernel events layer
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.132 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site