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

[Freeciv-Dev] snprintf, again

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] snprintf, again
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Thu, 19 Aug 1999 12:36:25 +1000 (EST)

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]