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

[Freeciv-Dev] Re: snprintf, again

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: snprintf, again
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Sun, 22 Aug 1999 23:38:21 +1000 (EST)

I think the following post got eaten by the Listar (mis)feature 
of "lets pretend this post is a Listar command request".  
Lets try again:  (quoted text is the message :-)

> A while back there was some discussion and patches for adding
> an implemention of snprintf [1] for those platforms which don't
> have it, so that freeciv would have this function available to 
> help protect against buffer overruns.
> 
> 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)
>   - *not* foolproof, but:
>     - allows full advantage of real snprintf on systems which have 
>       the real function;
>     - 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.
> 
> Regards,
> -- David
> 
> [1] For snprintf, really read vsnprintf, and would implement
>     snprintf in terms of that.
> 
> 

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