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: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: Re: [Freeciv-Dev] snprintf, again
From: Alex Zepeda <jazepeda@xxxxxxxxxxx>
Date: Wed, 25 Aug 1999 13:05:11 -0700 (PDT)

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 :^)

> (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'').

(From the FreeBSD man page).

> 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 not sure why Cygwin doesn't have snprintf, a quick search of
Microsoft's own site turns up references to snprintf.  When I get to a box
with MSVC++ on it tomorrow, I'll double check this.

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?!).

I am curious though, what platforms don't have snprintf, and which have
vsnprintf but no 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?

Anyways, I think I'll start looking at what should be using snprintf and
vsnprintf, since I've got a box with snprintf in its libc :^).  Once that
is done, I figure, any implementation could be dropped in there.  Or has
this already been done?

- alex


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