9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <qunastro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: [9fans] snprint(), getfields() specification
Date: Thu, 10 May 2001 13:40:08 -0400	[thread overview]
Message-ID: <20010510174008.A07FC3EA0A@quanstro.net> (raw)

> 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



             reply	other threads:[~2001-05-10 17:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-10 17:40 erik quanstrom [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-05-10 17:56 rob pike
2001-05-10 17:51 forsyth
2001-05-10 16:56 rob pike
     [not found] <rob@plan9.bell-labs.com>
2001-05-10 14:59 ` rob pike
2001-05-10 16:42   ` Scott Schwartz
2001-05-10 18:13   ` Steve Kilbane
2001-05-10 21:38     ` Boyd Roberts
2001-05-11  6:51       ` Steve Kilbane
2001-05-10 14:30 rob pike
2001-05-11  8:33 ` Douglas A. Gwyn
2001-05-14  8:36 ` David Rubin
2001-05-10 13:56 rob pike
2001-05-10 14:25 ` Greg Hudson
2001-05-10 14:44   ` William Josephson
2001-05-10  5:11 Scott Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010510174008.A07FC3EA0A@quanstro.net \
    --to=qunastro@quanstro.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).