Complete.Org: Mailing Lists: Archives: freeciv-dev: August 1999:
Re: [Freeciv-Dev] snprintf, again
Home

Re: [Freeciv-Dev] snprintf, again

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jazepeda@xxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] snprintf, again
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Wed, 25 Aug 1999 21:56:13 +1000 (EST)

Alex Zepeda wrote:

> The Cygwin toolkit presumably already posses a respectable stdio
> implementation, 

That's what I had expected, but last time this came up someone 
said that Cygwin doesn't have snprintf.

> > Its true the the Gtk+ people have presumbaly already solved most of
> > these problems, but I am concerned about how ultimately portable,
> > bug-free and maintainence-free implementations like this are going to
> > be.
> 
> This will quite frankly never happen with any solution.  It's always going
> to require some work no matter how minor.

How minor is the question.  This is exactly why I like my proposed 
incredibly simple and incredibly portable method!  :-)

Of course the catch is that its not 100% safe, but I think 
it's likely to catch almost all "natural" cases, and I suspect 
failure should probably be detectable, because it will mean 
overrunning a buffer in the heap rather than on the stack. 

(My other previous very simple/portable solution involved using
tmpfile(), which has the advantage of being 100% safe, but the 
disadvantage of possibly very bad performance.  Though maybe
not, depending on the filesystem.  Also does require a working 
tmpfile() available, which I'm not 100% sure of.)

> When (most likely if) I drop in snprintf, I'll most likely take Theo's
> implementation.  It's small, tidy and it works w/ Solaris[1].  

Hmm, the Solaris I have access to appears to have native 
vsnprintf anyway.

> If it
> doesn't work on MacOS or Win32, well, some *other* solution should be
> worked out for those platforms, while maintaing simple code on the
> platforms that support it.

Urg.  I forgot another constraint: I don't want to have to
maintain _multiple_ vsnprintf replacements... :-/

> * What about not using sprintf unless you know the size.  This might
> include using strcat or perhaps truncating incomming packets (but this
> leaves 18n'd strings).

You can do things like this, but it means a lot of hassle for 
the programmer, to all the time try to estimate maximum buffer 
sizes and keep track of string lengths etc.

(Note in particular one can use the precision to limit the 
length of printed strings, eg, format "%.63s", or even
eg ("%.*s", max_len, str).)

Also a problem is for freeciv-implemented "printf-like" functions 
which use vsprintf() internally, where its then a further hassle 
to be very careful with all the invocations of such functions.

Regards,
-- David

[Prev in Thread] Current Thread [Next in Thread]