Guessing buffer size needed for sprintf beforehand

Jill Diewald jad at insyte.uucp
Fri Apr 29 01:51:29 AEST 1988


Hi-

I'm having a problem with sprintf because it requires my knowing
how big a buffer to supply.  The IO module of our program needs
to sprintf into its internal output buffer - which is dynamically
allocated.  By the time the the call to the IO module happens, 
all the IO function knows is what it is passed as arguments. 
(It is a very well structured modular system).  The IO call looks 
like a vprintf and has the same arguments.  The IO routine does 
not know how many characters there are to print until sprintf 
returns that number, by then it it too late!

The original approach was to set a fudge factor of 256.  Unfortunately
this is not good enough.  We ran into this problem by a user doing 
a particularly strange thing ...but you know how end users are...
Seriously though, the system is used to produce very large reports so 
we need a fool proof solution.

I can see some solutions but none of them are particularly nice.
Two constraints, the solution has to be FAST and portable since
the system is run on many computers including VMS.

One solution is to fprintf into a file opened to be /dev/null.
This requires two calls to the c print fuctions, one to get the
size and the second to actually print.  Since the first call
goes to dev/null it should be faster since it doesn't really
write anything? (Is this true?  For all UNIXs?).  This won't
work for VMS though.

Another solution is to parse the printf format and arguments and
create my own count.  This would be non-trivial since there are
so many different formats and sort of like re-inventing the wheel
since printf already does this.

Is there some function out there that does the parsing and returns
a count?

Is there another approach?  Two calls to a print function for every
line is probably too slow.

Any ideas would be appreciated

	Jill Diewald
	Innovative Systems
	Newton, MA 
	(617) 965-8450
	...harvard!axiom!insyte!jad



More information about the Comp.unix.wizards mailing list