I've been following the recent thread on the linux security list
relating to the snprintf function.
I'm not worried about the problems reported with the snprintf,
mostly because my mud no longer runs on Linux :-) Those of
you who aren't aware of the problem should note that snprintf
on some Linux boxes doesn't do the bounds checking that it's
supposed to.
Which brings me to the reason for this post:
Has anyone on the list converted their use of sprintf to snprintf?
The reason I ask is that I'm currently on a code cleanup phase,
and am trying to account for all memory used, and to validate
all memory storage routines (bounds checking, etc.) snprintf
seems an ideal function, as bounds checking is rather less
painful with that ability.
This is yet another call in the standard library that I have missed
while combing it looking for functions to add to the toolkit. It is
really amazing the stuff that is defined in ANSI C that I see value
in, but rarely see anyone use. Is there a reason for this? Problems
maintaining portability? Laziness on the part of a good many
coders? :-)
FYI: MSVC, Linux and FreeBSD define it in stdio.h. Anyone know
of an os that doesn't define snprintf? It's in the standard library, so
I would assume most, if not all would have it...
Thanks for any input,
--Mallory
P.S. For those that have no idea of what snprintf does, I've included
the following excerpt from the msvc help file.
int _snprintf( char *buffer, size_t count, const char *format [, argument]
... );
_snprintf returns the number of bytes stored in buffer, not counting the
terminating null character. If the number of bytes required to store the
data exceeds count, then count bytes of data are stored in buffer and
a negative value is returned. "Never worry about the bullet with your name on
it. Instead, worry about
shrapnel addressed to 'occupant.'" --Murphy
+-----------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://cspo.queensu.ca/~fletcher/Circle/list-faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST