Subject: Re: snprintf()
To: new-httpd@hyperreal.com
Date: Wed, 8 Jan 1997 09:50:43 +0000 (GMT)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
In-Reply-To: <199701080142.UAA28913@shado.jaguNET.com> from "Jim Jagielski" at
 Jan 7, 97 08:42:11 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID: <9701080950.aa07416@gonzo.ben.algroup.co.uk>
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

Jim Jagielski wrote:
> 
> Dean Gaudet wrote:
> > 
> > Other than varags issues (which I think we've already made portable
> > because of other functions we've got) ... how hard would it be to make an
> > snprintf that parses the string and uses native sprintf() to do the dirty
> > work for each piece?
> > 
> > Doing things piece by piece it is pretty easy to limit how much native
> > sprint will write.
> > 
> 
> Hmmm... I'm guessing you mean if snprintf() is given, for example,
> ("%d %s %s", val, str, nstr) we would do "subcontract" it out as
> sprintf(buf, "%d", val) - adjust buf - sprintf(buf, "%s", str) ....
> Hmmm, would be even better if, while doing that we "adjust" the
> format statements to include precision values based on the 'len'
> parameter and keep reducing that as the buf is used up. Tricky but
> do-able. If the recently posted snprintf() doesn't work, I'm all
> for trying this approach.

This is pretty much how bprintf() works already. I'd say that it should be
possible to make a lower-level version which did both bprintf and snprintf.

I may have a crack at it if people want.

Speaking of having cracks at things - what about the API change and related
patches?

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author