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: Thu, 26 Aug 1999 11:23:44 +1000 (EST)

Alex Zepeda wrote:
> On Wed, 25 Aug 1999, David Pfitzner wrote:
> 
> > 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. 
> 
> Ehm, buffer overflows are hardly natural :^)

By natural, I mean when the programmer (or user) does not
do something deliberate (or foolish) to overflow 64k worth
of buffer.

Also, one may use snprintf with n deliberately smaller than 
the size which would otherwise be printed, which would be 
handled properly by my method (unless the size is 
"unnaturally" large).

> > (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.)
> 
> STANDARDS
>      The tmpfile() and tmpnam() functions conform to ISO 9899: 1990 (``ISO
>      C'').

Yes, but I believe it is permitted by the standard for tmpfile() 
to return NULL.   (And eg we found it necessary to provide 
mystrerror despite strerror being in the standard.)

> > Urg.  I forgot another constraint: I don't want to have to
> > maintain _multiple_ vsnprintf replacements... :-/
> 
> Are you maintaining the Win32 port right now?

I'm (co-)maintaining freeciv.

> The thing is, when you get a single piece of code that does all this for
> many platforms, you sacrafice something.  In this case saftey or speed
> (opening another file for snprintf?!).

Only _open_ a single file the first time it is called.
Then write/rewind/read/rewind each call.  

Remember all such disadvantages only apply on platforms which 
don't have a real snprintf...  And safety will still be no less
(indeed will be more) than current freeciv.

> I am curious though, what platforms don't have snprintf, 

> and which have
> vsnprintf but no snprintf?

You mean the other way around.  We need vsnprintf, but given
vsnprintf we can simulate snprintf.

> > 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.
> 
> Have I mentioned, I think printf and the printf family are evil?

Well, such functions are not going to disappear from freeciv
in the near future.

Regards,
-- David

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