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