>> [...discussion of code using multiple snprintfs to assemble a string
>> into a buffer...]
> One easy possibility for snprintf modifications would be a
> snprintf_seq which takes pointers to the buffer pointer and length
> and increments the buffer pointer and decrements the length by the
> amount actually written.

> An even better option, IMO, would be to use a string buffer structure
> that contains the buffer pointer, buffer size, and the current
> length.  [...]

In userland, I use funopen() with a handful of auxiliary functions to
handle this sort of thing:

	FILE *f;

	f = fopen_write(buffer,maxlength); /* layered over funopen(3) */
	fprintf(f,...);
	fprintf(f,...);
	fprintf(f,...);
	fclose(f);

(Since I haven't built a version that I use across multiple programs,
the interface varies slightly from program to program, depending on
what it gets used for.  I like to reinvent a wheel some five to ten
times before I feel I have a good enough handle on it to build a
reusable wheel, at least when it's something this small and simple.)

Now, my first reaction to thinking of this in a kernel context is that
importing enough of stdio into the kernel to actually do that would be
overkill.  But on reflection, I'm not so sure.  The complicated parts
of stdio are the fancy buffer dancing (which doesn't apply if all you
use is funopen()) and doprnt (which in essence we need in the kernel
anyway).  Adding enough of stdio to support funopen() might actually be
little enough code to be worth it.  (How much the interface should look
like userland stdio's is another question, of course.)

Thoughts?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B