From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] snprint(), getfields() specification 
From: "rob pike" <rob@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010510165622.E3C3C199F0@mail.cse.psu.edu>
Date: Thu, 10 May 2001 12:56:20 -0400
Topicbox-Message-UUID: 9e025e48-eac9-11e9-9e20-41e7f4b1d025

The 9P2000 version of the Plan 9, with all its variable-sized pieces,
has this problem in many places.  I don't think a single best solution
exists, nor that this idea works for snprintf, but for example: In the
new stat, the buffer might not be long enough for the full entry.  In
that case, the return value is 2, which could never otherwise be the
right answer, and the first two bytes of the buffer contain the
required length.  (The first two bytes of any stat buffer hold the
length of the entire object.)  In the manner intended, I believe, for
snprintf, you have a chance to reallocate and retry.

A word for consistency: the return value is, as traditional, the
number of bytes affected by the operation that actually happened.

If you want to know big a buffer is required for snprintf, two methods
strike me as better than the C99 approach: some sort of length routine
that in practice you could always call (avoiding the retry case), or a
separate return path, such as an int*.  In practice, I probably
wouldn't use either, since I use snprint purely for safety, almost
never expecting a truncated answer and not really caring if I get one.
The C99 definition makes my standard usage more convoluted to achieve.

If I had to pick one, I'd go for the length routine.  If you really
care, always use it; if you never care, you want the actual number of
bytes and the snprint (not snprintf) result seems better.

-rob