Re: [PATCH 1/5] scsi: BusLogic: Fix missing `pr_cont' use

[Maciej W. Rozycki]

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