From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <qunastro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: [9fans] snprint(), getfields() specification
Message-Id: <20010510174008.A07FC3EA0A@quanstro.net>
Date: Thu, 10 May 2001 13:40:08 -0400
Topicbox-Message-UUID: 9e1dd1f0-eac9-11e9-9e20-41e7f4b1d025

> The getfields() manpage says,
> 
> 	If there are more than maxargs fields, only the first maxargs
> 	fields will be set.
> 	...
> 	Getfields return the number of tokens processed.
> 
> snprint() says something similar.
> 
> In both cases, if the limit is too small, there's no way to find out
> how much space you actually needed.  Unix snprintf returns that value;
> compare with the limit to know if you need to allocate more space,
> or emit an error, or just use what you got.
> 
> I think we might be better off adopting that convention.

actually, the unix snprint (linux) says:

RETURN VALUE
       If the output was truncated, the return value is -1, otherwise it is the
       number of characters stored, not including the terminating null.


i don't see a problem with snprint() truncating the output -- you
shouldn't be using it if you don't have a maximum size in mind to begin with.
the n in snprint is just a fencepost.

what would be nice, though, is mprint(), which scott's very own print
library provides. mprint() allocates enough memory for whatever string
you want to format, and returns the buffer. very nice.

as an aside, i've added "long" formats to scott's library. they're
of the form "%{list %s}", for example. we were using installable
formats on a largish project where we had a lot of need to print out
this or that. it was quite a help to expand the namespace, in our
project. also, %{md5sum} is quite a lot more readable and unambiguous
than %M (which is probablly used anyway).

if there's any interest, i'd be happy to package up my mods & post them.

erik