Difference between strcpy() and strcat()?

Discussion in 'C Programming' started by Pascal Damian, Mar 5, 2004.

  1. I read somewhere that strcpy() is safer when dealing with malloc()-ed
    strings. Is that true?

    (Of course I know that both are unsafe).

    --
    Pascal
    Pascal Damian, Mar 5, 2004
    #1
    1. Advertising

  2. Pascal Damian

    -berlin.de Guest

    Pascal Damian <> wrote:
    > I read somewhere that strcpy() is safer when dealing with malloc()-ed
    > strings. Is that true?
    > (Of course I know that both are unsafe).


    This question is like: "I read somewhere that handling sodium instead
    of potassium is safer in a humid enviroment. Is that true?"

    They do different things. Use strcpy() if you want to copy a string and
    strcat() when you need to append a string to another one. Of course,
    you can use strcpy() instead of strcat() if you want (and don't mind
    the time needed for an additional function call to find the end of
    the first string) but there is no additional inherent safety in using
    one or the other.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
    -berlin.de, Mar 5, 2004
    #2
    1. Advertising

  3. Pascal Damian

    Leor Zolman Guest

    On 4 Mar 2004 18:25:54 -0800, (Pascal Damian)
    wrote:

    >I read somewhere that strcpy() is safer when dealing with malloc()-ed
    >strings. Is that true?
    >
    >(Of course I know that both are unsafe).


    I've not read anything to that effect, but I can easily imagine someone,
    somewhere having at some point said something like:

    "strcpy is safer than strcat because it is easier to check programmatically
    that a strcpy operation will not overflow the buffer: presumably you know
    the length of your destination buffer, so all you have to do is check the
    length of the source string. With strcat, on the other hand, you have to
    test the length of the existing string in the buffer, add the length of the
    string to be appended, and make sure the total resulting length is going to
    fit into your available space."

    But that would actually be rubbish...I've probably had more overruns with
    functions like strcpy than with strcat. Why? Because I've been more
    /careful/ while using strcat... ;-)
    -leor


    Leor Zolman
    BD Software

    www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
    C++ users: Download BD Software's free STL Error Message
    Decryptor at www.bdsoft.com/tools/stlfilt.html
    Leor Zolman, Mar 5, 2004
    #3
  4. Pascal Damian

    Mik Mifflin Guest

    -berlin.de wrote:

    > Pascal Damian <> wrote:
    > Of course,
    > you can use strcpy() instead of strcat() if you want (and don't mind
    > the time needed for an additional function call to find the end of
    > the first string) but there is no additional inherent safety in using
    > one or the other.
    > Regards, Jens


    And strcat doesn't need to find the end of the first string?

    I only use strcpy when I've just allocated enough space for the string, or I
    keep a close eye on the buffer sizes and I know it's not going to overflow.
    In all other places, I use strncpy and strncat.

    --
    - Mik Mifflin
    Mik Mifflin, Mar 5, 2004
    #4
  5. Pascal Damian

    Richard Bos Guest

    Mik Mifflin <> wrote:

    > -berlin.de wrote:
    >
    > > Pascal Damian <> wrote:
    > > Of course,
    > > you can use strcpy() instead of strcat() if you want (and don't mind
    > > the time needed for an additional function call to find the end of
    > > the first string) but there is no additional inherent safety in using
    > > one or the other.

    >
    > And strcat doesn't need to find the end of the first string?


    Yes, but it may be able to do so more efficiently. For one thing,
    strlen() followed by strcpy() is two function calls, strcat() only one.
    No guarantees, of course (the Standard doesn't guarantee _anything_
    where efficiency is concerned), but I know where I'd put my money.

    > I only use strcpy when I've just allocated enough space for the string, or I
    > keep a close eye on the buffer sizes and I know it's not going to overflow.
    > In all other places, I use strncpy and strncat.


    Don't use strncpy() unless you know exactly why it is usually
    inadvisable to use strncpy(). Use *dest='\0'; strncat(); instead.

    Richard
    Richard Bos, Mar 5, 2004
    #5
  6. Pascal Damian

    nrk Guest

    Richard Bos wrote:

    > Mik Mifflin <> wrote:
    >
    >> -berlin.de wrote:
    >>
    >> > Pascal Damian <> wrote:
    >> > Of course,
    >> > you can use strcpy() instead of strcat() if you want (and don't mind
    >> > the time needed for an additional function call to find the end of
    >> > the first string) but there is no additional inherent safety in using
    >> > one or the other.

    >>
    >> And strcat doesn't need to find the end of the first string?

    >
    > Yes, but it may be able to do so more efficiently. For one thing,
    > strlen() followed by strcpy() is two function calls, strcat() only one.
    > No guarantees, of course (the Standard doesn't guarantee _anything_
    > where efficiency is concerned), but I know where I'd put my money.
    >
    >> I only use strcpy when I've just allocated enough space for the string,
    >> or I keep a close eye on the buffer sizes and I know it's not going to
    >> overflow. In all other places, I use strncpy and strncat.

    >
    > Don't use strncpy() unless you know exactly why it is usually
    > inadvisable to use strncpy(). Use *dest='\0'; strncat(); instead.
    >


    This is silly advice. strncpy is perfectly usable and safe as long as you
    understand what it is supposed to do. There may be performance reasons to
    avoid strncpy, but any other reason is unnecessary paranoia. If you're not
    careful when you program in C, you'll get burnt, regardless of how many
    library functions you assiduously avoid. I am not sure why everyone gets
    worked up about strncpy possibly not null terminating the string. It is
    quite straight forward to check if it has done so or not. If you blindly
    substitute strncat for strncpy you'll be in for some surprises as strncat
    may write n+1 characters and not n.

    -nrk.

    > Richard


    --
    Remove devnull for email
    nrk, Mar 5, 2004
    #6
  7. Leor Zolman <> wrote in message news:> "strcpy is safer than strcat because it is easier to check programmatically
    > that a strcpy operation will not overflow the buffer: presumably you know
    > the length of your destination buffer, so all you have to do is check the
    > length of the source string. With strcat, on the other hand, you have to
    > test the length of the existing string in the buffer, add the length of the
    > string to be appended, and make sure the total resulting length is going to
    > fit into your available space."
    >
    > But that would actually be rubbish...I've probably had more overruns with
    > functions like strcpy than with strcat. Why? Because I've been more
    > /careful/ while using strcat... ;-)


    To Jens,

    Yes, sorry. The question should be: "what's the difference between
    using strcat() or strcpy() to append a string?"

    To Leor,

    Here's exactly where I read it, from a post at comp.lang.ruby:

    ======================== start quote ============================
    > p = (char *)getenv("LD_LIBRARY_PATH");
    >> if ((env = (char *)malloc(512+1+(p==NULL ? 0:strlen(p)))) ==

    NULL) {
    >> fprintf(stderr, "malloc() failed: %s\n", strerror(errno));
    >> exit(1);
    >> }
    >> strcat(env, "LD_LIBRARY_PATH=");


    Use strcpy instead of strcat here, content of malloc'ed area is
    not guaranteed.
    ======================== end quote ============================

    URL: http://groups.google.com/groups?hl=
    URL: http://tinyurl.com/393yz

    Now what does the poster mean by "content of malloc'ed area is not
    guaranteed"?

    --
    Pascal
    Pascal Damian, Mar 5, 2004
    #7
  8. Pascal Damian

    -berlin.de Guest

    Pascal Damian <> wrote:
    > Here's exactly where I read it, from a post at comp.lang.ruby:


    > ======================== start quote ============================
    >> p = (char *)getenv("LD_LIBRARY_PATH");
    >>> if ((env = (char *)malloc(512+1+(p==NULL ? 0:strlen(p)))) ==

    > NULL) {
    >>> fprintf(stderr, "malloc() failed: %s\n", strerror(errno));
    >>> exit(1);
    >>> }
    >>> strcat(env, "LD_LIBRARY_PATH=");


    > Use strcpy instead of strcat here, content of malloc'ed area is
    > not guaranteed.
    > ======================== end quote ============================


    > Now what does the poster mean by "content of malloc'ed area is not
    > guaranteed"?


    strcat() appends to a '\0'-terminated string (first searching for
    that value to figure out where to write to), but the malloc()-ed
    memory isn't initialized. While there may be a `\0' somewhere in
    that memory just by chance, there's no guarantee that the first
    char of the memory is '\0'. But that would be the requirement if
    you want to use strcat() instead of strcpy(). So the author of
    that article is just pointing out a bug in the logic of the code
    - most likely the string "LD_LIBRARY_PATH=" is going to be written
    to some random location in memory, possibly outside the malloc()-ed
    area. If you insist on using strcat() in this case you would need
    set the first char in the memory to '\0' first (or use calloc() to
    obtain the memory).
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
    -berlin.de, Mar 5, 2004
    #8
  9. Pascal Damian

    Leor Zolman Guest

    On 5 Mar 2004 04:18:39 -0800, (Pascal Damian)
    wrote:
    >Here's exactly where I read it, from a post at comp.lang.ruby:
    >
    >======================== start quote ============================
    >> p = (char *)getenv("LD_LIBRARY_PATH");
    >>> if ((env = (char *)malloc(512+1+(p==NULL ? 0:strlen(p)))) ==

    >NULL) {
    >>> fprintf(stderr, "malloc() failed: %s\n", strerror(errno));
    >>> exit(1);
    >>> }
    >>> strcat(env, "LD_LIBRARY_PATH=");

    >
    >Use strcpy instead of strcat here, content of malloc'ed area is
    >not guaranteed.
    >======================== end quote ============================
    >
    >URL: http://groups.google.com/groups?hl=
    >URL: http://tinyurl.com/393yz
    >
    >Now what does the poster mean by "content of malloc'ed area is not
    >guaranteed"?


    Along with what Jens said, I think this kinda goes along with what I was
    saying. There's more "stuff" to think about when using strcat; Personally,
    I would never dream of using it "in place of" strcpy; the question just
    wouldn't arise because I'm totally acclimated to what each of them does and
    would pick the one most suitable to the task in the first place [and this
    would probably be the wrong group to mention that, these days, I'd use
    std::string in C++ and try to avoid str*() whenever possible, so I won't
    say it... ;-) ]. The question isn't "which one is safer"; the lesson is:
    research well what /any/ function does before you use it!
    -leor

    Leor Zolman
    BD Software

    www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
    C++ users: Download BD Software's free STL Error Message
    Decryptor at www.bdsoft.com/tools/stlfilt.html
    Leor Zolman, Mar 5, 2004
    #9
  10. -berlin.de wrote in message news:
    > strcat() appends to a '\0'-terminated string (first searching for
    > that value to figure out where to write to), but the malloc()-ed
    > memory isn't initialized. While there may be a `\0' somewhere in
    > that memory just by chance, there's no guarantee that the first
    > char of the memory is '\0'. But that would be the requirement if
    > you want to use strcat() instead of strcpy(). So the author of
    > that article is just pointing out a bug in the logic of the code
    > - most likely the string "LD_LIBRARY_PATH=" is going to be written
    > to some random location in memory, possibly outside the malloc()-ed
    > area. If you insist on using strcat() in this case you would need
    > set the first char in the memory to '\0' first (or use calloc() to
    > obtain the memory).


    Of course. I did remember this from years, years back. Thanks for the
    verbose and clear explanation.

    --
    Pascal
    Pascal Damian, Mar 6, 2004
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JC

    strcpy and strcat problem

    JC, Sep 26, 2003, in forum: C Programming
    Replies:
    23
    Views:
    1,889
    Robert B. Clark
    Sep 29, 2003
  2. Jarmo
    Replies:
    44
    Views:
    1,738
    Irrwahn Grausewitz
    Nov 26, 2003
  3. Matt
    Replies:
    82
    Views:
    1,764
    Douglas A. Gwyn
    Sep 29, 2004
  4. strcpy and strcat's return type

    , Jul 26, 2005, in forum: C Programming
    Replies:
    14
    Views:
    801
    Kenneth Brody
    Aug 22, 2005
  5. =?ISO-8859-1?Q?Une_b=E9vue?=

    [newbie] strcpy, strtok and strcat problem...

    =?ISO-8859-1?Q?Une_b=E9vue?=, Aug 31, 2006, in forum: C Programming
    Replies:
    16
    Views:
    1,229
    =?ISO-8859-1?Q?Une_b=E9vue?=
    Sep 1, 2006
Loading...

Share This Page