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: Mon, 23 Aug 1999 20:26:40 -0700 (PDT)

> I've now thought of an implemention of snprintf which has 
> the following advantages:
>   - incredibly simple (I don't want to have to support/maintain 
>     half a stdio package...)
>   - incredibly portable (no unixy mem_protect tricks)

>     - on systems which don't have real snprintf, don't have too 
>       much loss in performance/functionality, and still get some 
>       protection against buffer over-runs, and in particular _more_ 
>       protection than currently (where typically just use plain 
>       sprintf to moderate sized buffer).

> The method:
>   - first time called, malloc a big buffer, larger than we are
>     likely to ever need for a single snprintf (eg, say 64k)
>   - sprintf to that buffer
>   - maybe try to detect over-run after the event, and abort() if so
>   - copy the appropriate number of chars from buffer to destination
> 
> The main thing I have to check on is what exact semantics snprintf 
> is supposed to have when the output size would be too long.

Say what you will, but I think that grabbing an appropiate copy of
snprintf and vnprintf is a very easy thing to do, and will require very
little maintenence.  Snprintf would be implemented on top of vnprintf
which if not available would be IIRC implemented on top of vprintf which
nearly everything has AFAIK.

For example, Apache, ssh, KDE, Qt, and IIRC even Gnome have snprintf
implemented in a rather portable manner.  Finding a ready made copy is IMO
much easier than reinventing the wheel.

- alex


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