Re: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote:
> On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > -	seq_printf(m, "%s%d%n", con->name, con->index, &len);
> > > +	len = seq_printf(m, "%s%d", con->name, con->index);
> > 
> > Isn't len always 0 or -1 ?
> 
> Right.  Well you're no fun...
> 
> These uses would seem broken anyway because the
> seq_printf isn't itself tested for correctness.
> 
> Hmm.
> 
> Also, there's a large amount of code that appears
> to do calculations with pos or len like:
> 
> 	pos += seq_printf(handle, fmt. ...)

... and most of that code proceeds to ignore pos completely.
Note that ->show() is *NOT* supposed to return the number of
characters it has/would like to have produced.  Just return
0 and be done with that; overflows are dealt with just fine.
The large amount, BTW, is below 100 lines, AFAICS, in rather
few files.

> There are very few that seem to use it correctly
> like netfilter.

> Suggestions?

Just bury the cargo-culting crap.  All those += seq_printf() should
be simply calling it.  The *only* reason to look at the return
value is "if we'd already overflown the buffer, I'd rather skipped
the costly generation of the rest of the record".  In that case
seq_printf() returning -1 means "skip it, nothing else will fit and
caller will be repeating with bigger buffer anyway".
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux