[CRIU] Re: [PATCH 3/4] pr_perror(): print error at the end of line
Pavel Emelyanov
xemul at parallels.com
Tue Jan 31 02:55:27 EST 2012
On 01/31/2012 11:01 AM, Cyrill Gorcunov wrote:
> On Tue, Jan 31, 2012 at 03:15:07AM +0400, Kir Kolyshkin wrote:
> ...
>>>
>>> +void printk_strerrno(const char *format, ...)
>>> +{
>>> + char buf[1024];
>>> + va_list params;
>>> + int npos;
>>> +
>>> + va_start(params, format);
>>> + vsnprintf(buf, sizeof(buf), format, params);
>>> + va_end(params);
>>> +
>>> + npos = strlen(buf) - 1;
>>> + if (buf[npos] == '\n')
>>> + buf[npos] = '\0';
>>> + else
>>> + npos = -1;
>>> +
>>> + strncat(buf, ": ", sizeof(buf));
>>> + strncat(buf, strerror(errno), sizeof(buf));
>>> +
>>> + if (npos != -1)
>>> + strncat(buf, "\n", sizeof(buf));
>>> +
>>> + dprintf(get_logfd(), "%s", buf);
>>> +}
>>> +
>>>
>>
>> Well frankly speaking it looks pretty ugly to me:
>> 1. Looks complex.
>> 2. Artificial limit (1024) on resulting string size (could use
>> vasprintf() here)
>> 3. strncat() invocations are inefficient, they scan buf from the
>> beginning till the end every time looking for \0, which you already
>> did.
>
> yes, but as I say it's not that important if this function is
> called.
>
>> 4. dprintf() looks like an overkill, what's wrong with write()?
>
> just to use a pair of vdprintf
>
>> 5. It doesn't handle the case with multiple \n at the end of format string.
>>
>> Anyway, I came up with what I think is a slightly better version of
>> the above. Still looks ugly to me though:
>> 1. It still looks complex.
>> 2. It still doesn't handle the case with multiple \n at the end.
>>
>> If you and Pavel can tolerate it, let me know and I will redo my
>> patch #3 with this one:
>>
>
> Looks pretty good to me! Pavel?
OK
> Cyrill
> .
>
More information about the CRIU
mailing list