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 04:18:23 -0700 (PDT)

On Wed, 25 Aug 1999, David Pfitzner wrote:

> I'm thinking Win32 and Mac are the main candidates.   
> Maybe SunOS too, which seems weird/lacking in many respects, 
> although that's a rather low importance target nowadays :-)
> 
> Regarding potential Win32 solutions: please be more specific.

The Cygwin toolkit presumably already posses a respectable stdio
implementation, but I've got a sneaking suspicion that Microsoft has
already included snprintf in MSVCRT.DLL (a quick check of Wine seems to
affirm this).

> 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.  While I abhor the Gnome
autoconf bastardization, it would appear to work.

> Speaking of what can be "easily" done, this argument can of course be
> "easily" settled by submitting a patch to add whichever snprintf you
> favour to freeciv, and getting freeciv people to test it on their
> platforms...

Which I will certianly try to do.  I took a really bad time to shoot my
mouth off as I'm just starting school.

But, I think that one can only take portability to a certian extent and
maintain sanity.

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].  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.

This of course raises a few thoughts in my mind:

* What about use of a true string class.  I would much favor QTL over STL
for size and speed (and it's more portable to boot), but STL offers many
of the same advantages. This would remedy the sprintf issues before they
become an issue but would introduce a probably unwanted dependency on C++.

* 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).

[1] I'm pretty sure it works on Solaris, because the KDE CVSmaster
primarily uses Solaris, and this is the implementation that has snuck in
there.

- alex


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