On Thu, 15 Apr 2021, Joe Perches wrote:
> In patch 2, vscnprintf should probably be used to make sure it's
> 0 terminated.
Why? C99 has this[1]:
"The vsnprintf function is equivalent to snprintf, with the variable
argument list replaced by arg, which shall have been initialized by the
va_start macro (and possibly subsequent va_arg calls)."
and then[2]:
"The snprintf function is equivalent to fprintf, except that the output
is written into an array (specified by argument s) rather than to a
stream. If n is zero, nothing is written, and s may be a null pointer.
Otherwise, output characters beyond the n-1st are discarded rather than
being written to the array, and a null character is written at the end
of the characters actually written into the array."
therefore output from `vsnprintf' is always null-terminated.
> And while it's a lot more code, I'd prefer a solution that looks more
> like the other commonly used kernel logging extension mechanisms
> where adapter is placed before the format, ... in the argument list.
I agree having `adapter' as the second argument seems weird, so that is
fine with me as a follow-up cleanup. However as a user-visible change I
think the fix I propose here ought to be applied first (and backported
as suitable). Then any internal clean-ups can follow, applied to trunk
only.
> And there's a simple addition of a blogic_cont macro and extension
> to blogic_msg to simplify the logic and obviousness of the logging
> extension lines too.
I did this first actually, before I realised a simpler change suitable
for backporting could be done. I'm not sure if that complex message
routing via `blogic_msg' is worth having even, rather than calling
`printk' or suitable variants directly.
References:
[1] "Programming languages -- C", INTERNATIONAL STANDARD, ISO/IEC 9899,
Second edition, 1999-12-01, Section 7.19.6.12 "The vsnprintf
function", p.293
[2] same, 7.19.6.5 "The snprintf function", p.289
Maciej
