On Mon, 2013-09-16 at 08:25 -0700, Kees Cook wrote: > On Mon, Sep 16, 2013 at 8:09 AM, Joe Perches <j...@perches.com> wrote: > > On Mon, 2013-09-16 at 07:59 -0700, Kees Cook wrote: > >> Perhaps instead of seq->count, there should be an access function? > >> seq_get_count(seq) or something? > > > > My thought was to add a seq_last_len() > > That would mean growing the size of the seq_file structure and adding > instructions for all users. While I personally have no problem with > that, I worry others might.
I don't think adding an int and a size_t is a big deal. I'm still hoping to hear from Al if expanding the struct is OK and race-free. > If we just use seq->count (or equivalent > function), then only those that want length will use it. I actually > think this uses fewer instructions than %n. Especially in the case > where seq_printf got replaced by seq_puts. :) Shrug. None of these are inline uses so the overall code size doesn't change much. I have patches that make seq_overflow public and replace the current uses of the seq_printf/seq_puts/seq_putc returns where appropriate. Given that I was already touching a lot of the seq_<foo> calls, I also have patches that convert all the seq_printf(fmt) (no additional args) to seq_puts() and all the seq_puts("[single char]") to seq_putc() as separate patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/