Manuel Bouyer <bouyer@antioche.lip6.fr> writes:
> Before adding other formats to the corename stuff I wonder if it's worth
> implemeting a generic function for this. Something like:
> strformat(char *dst, size_t dstlen, const char *template, const char *format,
>     ...);
> A sample call would be here:
> strformat(name, MAXPATHLEN, curproc->p_limit->pl_corename, "nup",
>     "%s", curproc->p_comm,
>     "%s", curproc->p_pgrp->pg_session->s_login,    
>     "%d", curproc->p_pid);
> That is, for each format we provide the snprintf format to convert the value,
> and the value.
> Would this be of general interest ?

it's not clear how useful/pretty this is, as-is, because of the way
varargs works.

strformat() itself would have to understand all of the snprintf-format
specifiers, in order to properly decode the variable arguments passed
to it (to either handle them itself, or pass them off to snprintf).
therefore, it makes me think you might have a better/more compact
representation of the data that would do the right thing...

it's also not going to be particularly efficient to format strings...
something like:

	i've got a %p in my input!  OK, it's the third type of format
	character i know about!

	va_start...

	get the first sprintf format with va_arg
	figure out what kind of argument goes with it
	advance past it with va_arg

	get the second sprintf format with va_arg
	figure out what kind of argument goes with it
	advance past it with va_arg
	
	get the third sprintf format with va_arg
	figure out what kind of argument goes with it
	fetch it with va_arg
	format it directly or pass it to snprintf

	va_end

	repeat for next input...

seems to me that there's gotta be a better way, but maybe there's not.  8-)


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.