RE: safe strcpy()?

From: Ed Carp (erc@pobox.com)
Date: 01/30/03

  • Next message: Crispin Cowan: "Re: safe strcpy()?" 
    Date: Wed, 29 Jan 2003 19:53:37 -0600 (CST)
From: Ed Carp <erc@pobox.com>
To: Daniel Reed <n@cs.rpi.edu>

    On Wed, 29 Jan 2003, Daniel Reed wrote:

    > Replacing strcpy()'s with strncpy()'s will not solve all problems,
    > and may in fact introduce new ones. In the above example, strncpy() did not
    > itself cause a problem, but its ignorant usage led to a misbehaviour.

    Replacing strcpy() with strncpy() does NOTHING to fix the destination
    overflow problem, which is a train wreck waiting to happen.

    > Using manipulation routines that ensure the string is large enough
    > to "hold" everything can lead to its own problems. A quick example: reading
    > data from the network; all someone need do is feed your service a constant
    > stream of characters, eventually the program will fill all available memory
    > trying to store the string. Again, it would be a programmer ignorantly
    > feeding a network socket directly into a string (as I've seen provided in
    > examples on this very list). However, in all of these cases, programmer
    > failure seems to be a common thread. There is no intrinsic flaw in the
    > methods or implementations they are using.

    The way to fix this is to just ignore everything that comes in when your
    buffer is full. Closing the socket is a rather effective, if rude<g> way
    to let the other side know it's sending you too much! 

    -- 
Ed Carp, N7EKG          http://www.pobox.com/~erc               214/986-5870
Licensed Texas Peace Officer
Computer Crime Investigation Consultant
Director, Software Development
Escapade Server-Side Scripting Engine Development Team
http://www.squishedmosquito.com
Microsoft Front Page - the official HTML editor of Al Qaeda
Microsoft Hotmail - the official email of Al Qaeda

    Relevant Pages

    • Safety and Interface design
      ... >>> I'm all for fixing incorrect usages of strncpy, ... The idea of introducing a safety belt is flawed since good drivers ... WHY should we require from the programmer this tedious stuff ... Good designed interfaces make errors harder to do. ...
      (comp.lang.c)
    • Re: C (functional programming) VS C++ (object oriented programming)
      ... for limited string copy and concatenation, ... Perhaps - but that is not what strncpy is for. ... Anyone not capable of understanding that strncpy is not supposed to be ... used as a "safe string copy" has no business being a programmer. ...
      (comp.lang.c)
    • Re: C (functional programming) VS C++ (object oriented programming)
      ... No abstraction, low level, dangerous procedures like strncpy ... You are either a very bad programmer or a troll. ... easy to misuse". ... If the compiler can determine that the pointer is incremented beyond the ...
      (comp.lang.c)
    • Re: Are bad developer libraries the problem with M$ software?
      ... strncpy does NOT append the trailing 0 if the ... This has left teeth marks on the posterior of more than one programmer, ...
      (SecProg)