Fix snprintf() overflow issues
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 3 May 2017 16:25:08 +0000 (12:25 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 4 May 2017 18:44:03 +0000 (14:44 -0400)
commit0f9842235194a8b815a3955046cb2868b1218f07
treedc329217b1e3dae41ffbe6c14123609919d6ee2d
parentff9442d85455c8efaf1048558a013d555f59bb1b
Fix snprintf() overflow issues

snprintf() is a pain.  Taking a 'negative' number for consecutive calls
after an overflow is a common pattern: see netif.c (derived from Plan 9)
and mlx4/mcg.c (from Linux).  We had been taking an int for the size, but
ought to be taking a size_t - if for nothing else than to make the change
now *and* adding the check, instead of later without the check.

On a similar note seprintf() was using its return value incorrectly.  The
uses of seprintf() seemed ok, since no one used "buf + rc" for anything
other than 'start' for another seprintf() call.  We could have seprintf()
do the same thing as snprintf(), but it seems a little dangerous to return
a pointer outside the [start, end) range.

One thing to remember is that if seprintf()/snprintf() overflowed, we
probably don't have a null-terminated buffer.  Some of our call sites might
not like that.

Similarly, the logic in parlib for detecting overflow was just wrong.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/include/stdio.h
kern/src/printfmt.c
tests/get_html.c
tests/srv.c
user/parlib/include/parlib/net.h
user/parlib/net.c
user/utest/devvars.c