On Mon, Nov 23 2015, Andy Shevchenko <[email protected]> wrote:
> On Mon, Nov 23, 2015 at 11:29 PM, Rasmus Villemoes > <[email protected]> wrote: >> If we're given a size of 0, the vsnprintf() won't have any side >> effects, and neither "i < size" or "size != 0" will trigger. So we >> might as well return 0 immediately. >> >> Signed-off-by: Rasmus Villemoes <[email protected]> >> --- >> lib/vsprintf.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/lib/vsprintf.c b/lib/vsprintf.c >> index 8af5535fd738..e22a6189548f 100644 >> --- a/lib/vsprintf.c >> +++ b/lib/vsprintf.c >> @@ -2036,13 +2036,14 @@ int vscnprintf(char *buf, size_t size, const char >> *fmt, va_list args) >> { >> int i; >> >> + if (unlikely(!size)) >> + return 0; >> + > > Might it potentially shadow any issue when run vsnprintf(buf, 0, fmt, > args); with certain arguments? Only if we ever come up with a %p extension with side effects, but then people couldn't rely on them happening exactly once anyway (kasprintf would make them happen twice). printf-like calls are also often compiled out or disabled (dyndebug, ratelimit, ...) without it being obvious at the call site whether they'll run or not, so I think such a hypothetical %p extension would meet some resistance. > I can imagine something like %pV with unstable pointer. I don't see how %pV is different than any other current %p extensions. Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
