snprintf vs strcat,

A

ajm

Hi,

I'm refactoring some HTTP client code I wrote a while back and in the
process I'm tightening up some of my string processing code (most of
which involves parsing, replacing, concatenating strings etc.).

I'm reading that it is better to use str functions like "snprintf" and
to avoid using "strcat" altogether since the former more explicit
protection against buffer overflow etc. Is this sort of comment good
advice ?

My priorities are security, standards (ANSI C/POSIX) then performance.
What say ye ?
ajm.
 
C

CBFalconer

ajm said:
I'm refactoring some HTTP client code I wrote a while back and in the
process I'm tightening up some of my string processing code (most of
which involves parsing, replacing, concatenating strings etc.).

I'm reading that it is better to use str functions like "snprintf"
and to avoid using "strcat" altogether since the former more explicit
protection against buffer overflow etc. Is this sort of comment good
advice ?

My priorities are security, standards (ANSI C/POSIX) then performance.
What say ye ?

Look into using strlcpy and strlcat, which were proposed and I
believe incorporated into BSD some time ago. They are much more
friendly and less error prone. You can find a portable
implementation and the associated justification and documentation
at:

<http://cbfalconer.home.att.net/download/strlcpy.zip>
 
M

Michael Wojcik

I'm refactoring some HTTP client code I wrote a while back and in the
process I'm tightening up some of my string processing code (most of
which involves parsing, replacing, concatenating strings etc.).

I'm reading that it is better to use str functions like "snprintf" and
to avoid using "strcat" altogether since the former more explicit
protection against buffer overflow etc. Is this sort of comment good
advice ?

You'll have to judge that for yourself, I'm afraid. Certainly the
overflow-guarding functions provide an extra check that's not
present in their non-guarding alternatives. However, people often
use strncpy and strncat incorrectly, and since buffer overflow has
to be handled somehow, some argue that you ought to find how long
your source strings are *before* trying to copy them - which makes
the additional guarding largely pointless.
My priorities are security, standards (ANSI C/POSIX) then performance.

Personally, I generally use the guarded versions (strncpy, strncat,
snprintf) in most cases. In some places overflow is handled by
silent truncation, because the program specification allows that; in
others the code has checked lengths already but uses the guarded
versions anyway just to protect against present or future logic
errors that might let an over-long parameter through. I'm not
concerned about the performance penalty, which is likely to be
negligible.

If you're concerned about standards, though, note that snprintf was
only added to the C standard in 1999, and that earlier versions of
the POSIX (SUS, etc) standard was inferior (it didn't let snprintf
distinguish between end-of-buffer and invalid-format conditions).
The current Microsoft Visual C snprintf implementation is still
broken this way, and some older Unix ones are as well (all of those
from HP, IIRC).

If your first priority is security - which I approve of - and you're
going to use C,[1] then I would recommend using the guarded string-
handling functions, or writing your own, or picking up someone else's
(if it's compliant and after vetting it). But I'd also recommend
thinking about how overflow should be handled, when silent truncation
is appropriate, and when the application should do something else;
and I'd recommend making explicit length checks where they seem
appropriate and not just relying on the string-handling functions to
do that for you.


1. There's been a lengthy flamewar recently in sci.crypt over whether
C is inherently bad for software security. I'm staying out of it,
as I think all the useful arguments on both sides have already been
aired.
 
A

ajm

thx for the feedback - this pretty much confirms what I thought.....

my idiom up to now has been to compute lengths + malloc, then
do my string stuff (for the most part I use my own memory mgr
for the former and has a few string wrappers/utils for the latter).

I am aware of strlcpy and co. but these are not POSIX as far as
I know (I write on *BSD but sometimes deploy onto Linux).

thx,
ajm.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top