On Wed, 9 Mar 2016 12:49:40 -0800 Andrew Morton <a...@linux-foundation.org> wrote:
> On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes > <li...@rasmusvillemoes.dk> wrote: > > > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer > > currently works, but it is somewhat fragile, and any other overlap > > between source and destination buffers would be a definite bug. This > > is an attempt at eliminating the relatively few occurences of this > > pattern in the kernel. > > I dunno, > > snprintf(analog->name, sizeof(analog->name), "Analog %d-axis %d-button", > > is pretty damn convenient. Can we instead state that "sprintf shall > support this"? Maybe add a little __init testcase to vsprintf.c to > check that it continues to work OK. We can just document that it does for the specific case. Or if anyone is worried it can easily be wrapped as sncatf() in case the property changes 8) If you go the seq_* way then IMHO a debug enabled check that no %s argument matches the passed source string in the kernel snprintf would be a good addition to go with it, so that the behaviour cannot be re-introduced. Given it works and it's useful and we have no reason to make it stop working I don't see why it shouldn't just be documented as a property of the kernel snprintf. The kernel makes plenty of other assumptions that are not strictly C standards compliant 8) Alan