Copying strings

Discussion in 'C Programming' started by Khookie, Dec 14, 2007.

  1. Khookie

    Khookie Guest

    Hi everyone

    Out of curiosity, would this be a valid implementation of a string
    copy function?

    int copy(char* to, char* from) {
    while (*to++ = *from++);
    }

    It's just that, I notice in string.h that it makes the 'from' argument
    a constant argument.

    char *strcpy( char *to, const char *from );

    Thus I suppose there needs to be some other pointer initialised to
    walk the from string.

    Is there a reason for this? I thought since the pointers are passed
    by value to the function, you wouldn't need to need to worry about the
    them being changed. Well, I thought you could save on the
    initialisation of another pointer, but given my ignorance of the
    language, I'm sure there's a good reason behind the const.

    Sorry if it sounds terribly pedantic, I'm just interested in learning
    why things are done a certain way.

    Chris
    Khookie, Dec 14, 2007
    #1
    1. Advertising

  2. Khookie

    Default User Guest

    Khookie wrote:

    > Hi everyone
    >
    > Out of curiosity, would this be a valid implementation of a string
    > copy function?
    >
    > int copy(char* to, char* from) {
    > while (*to++ = *from++);
    > }
    >
    > It's just that, I notice in string.h that it makes the 'from' argument
    > a constant argument.
    >
    > char *strcpy( char *to, const char *from );
    >
    > Thus I suppose there needs to be some other pointer initialised to
    > walk the from string.


    You are confused. That is a pointer to constant char, not a const
    pointer to char. That is, the pointer can change, but not what it
    points to.




    Brian
    Default User, Dec 14, 2007
    #2
    1. Advertising

  3. Khookie

    Ben Pfaff Guest

    Khookie <> writes:

    > Out of curiosity, would this be a valid implementation of a string
    > copy function?
    >
    > int copy(char* to, char* from) {
    > while (*to++ = *from++);
    > }


    Yes.

    > It's just that, I notice in string.h that it makes the 'from' argument
    > a constant argument.


    I think that you are confusing "const char *" with "char* const".
    In the former, the characters are const-qualified; in the latter,
    the pointer is const-qualified.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Dec 14, 2007
    #3
  4. Khookie

    pete Guest

    Khookie wrote:
    >
    > Hi everyone
    >
    > Out of curiosity, would this be a valid implementation of a string
    > copy function?
    >
    > int copy(char* to, char* from) {
    > while (*to++ = *from++);
    > }


    Your return type should be void instead of int.

    --
    pete
    pete, Dec 14, 2007
    #4
  5. Khookie

    Khookie Guest

    On Dec 14, 11:08 am, pete <> wrote:
    > Khookie wrote:
    >
    > > Hi everyone

    >
    > > Out of curiosity, would this be a valid implementation of a string
    > > copy function?

    >
    > > int copy(char* to, char* from) {
    > > while (*to++ = *from++);
    > > }

    >
    > Your return type should be void instead of int.
    >
    > --
    > pete


    ahh thanks everyone - I swore I got an error when compiling, but maybe
    that was something else

    void copy(char* to, const char* from) {
    while (*to++ = *from++);
    }
    Khookie, Dec 14, 2007
    #5
  6. Khookie

    CBFalconer Guest

    Khookie wrote:
    >
    > Out of curiosity, would this be a valid implementation of a string
    > copy function?
    >
    > int copy(char* to, char* from) {
    > while (*to++ = *from++);
    > }
    >
    > It's just that, I notice in string.h that it makes the 'from'
    > argument a constant argument.
    >
    > char *strcpy( char *to, const char *from );
    >
    > Thus I suppose there needs to be some other pointer initialised to
    > walk the from string.


    That const applies to the string itself, not the pointer. It says
    that strcpy will not modify the data pointed at by 'from'. This
    often allows improved optimization. There is no need to modify
    your code.

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Dec 14, 2007
    #6
  7. Khookie

    Chris Torek Guest

    >Khookie wrote:
    [with later correction applied]
    >> void copy(char* to, char* from) {
    >> while (*to++ = *from++);
    >> }

    [which is a valid implementation of "copy a string" a la strcpy(),
    except of course for the different return-type and (lack of) value]

    >> It's just that, I notice in string.h that it makes the 'from'
    >> argument a constant argument.
    >>
    >> char *strcpy( char *to, const char *from );


    Others (including Chuck Falconer below) have noted the differences
    between "const char *" and "char *const" and even "const char
    *const" (as types)...

    In article <>
    CBFalconer <> wrote:
    >That const applies to the string itself, not the pointer. It says
    >that strcpy will not modify the data pointed at by 'from'.


    Well, this promise is something of a phantom. In particular, you
    (the C programmer writing C code, not the implementor of strcpy()
    in this case) are allowed to "lie" about it, as it were:

    void avoid_this_bad_code_practice(const int *p) {
    *(int *)p = 42;
    }
    void call_the_bad_code(void) {
    int x;

    avoid_this_bad_code_practice(&x);
    /* now x == 42 */
    ...
    }

    The behavior of this is well-defined, despite the "lie" about the
    "const"-ness of *p in the first function. That is, the function
    whose name tells you not to write it makes a promise ("won't change
    *p") and then breaks it, in a way that the C Standard permits.
    Because of this and other problems outlined below, the claim:

    >This often allows improved optimization.


    is, I think, too strong. Careful and appropriate use of "const"
    *sometimes* allows improved optimization, but not really "often".
    In particular, rewriting copy() as:

    void copy(char *to, const char *from) {
    while (*to++ = *from++)
    continue;
    }

    gives the compiler no additional optimization opportunities,
    despite the addition of "const", because modifying to (for
    any index i) is allowed to change from[j] (for any index j).
    For instance:

    void weird(void) {
    char buf[12] = "hello";
    copy(&buf[6], &buf[0]);
    copy(&buf[0], &buf[1]);
    puts(buf);
    puts(buf + 6);
    }

    is well-defined, and must print "ello\nhello\n". (In this particular
    case, if modifying *to changes a "future" *from that will affect
    a "future" *to, the loop is unlikely to terminate at all, so the
    issues are rather fuzzy here.)

    More generally, a "const" qualifier prevents you from modifying
    the object yourself through the specific lvalue given, but does
    not prevent *other* modifications. It is perhaps easier to see
    the effect with the following, which is not as bad as the "broken
    promise" version:

    #include <stdio.h>

    int x = 42;

    void pr(const int *p) {
    printf("*p is %d\n", *p);
    x++;
    printf("*p is %d\n", *p);
    }

    int main(void) {
    pr(&x);
    return 0;
    }

    This program must print 42 and then 43 -- not 42 twice. The
    "const"-ness of *p implies that pr() is not going to change *p,
    and indeed it does not change *p by that name, but it *does*
    change x, and *p happens to be an "alias" for x -- and the
    C Standard requires that when x changes, *p change with it.
    Therefore, "const" does *not* tell the compiler "this is not
    going to change", and the compiler's optimizer cannot assume
    that it does not change.

    (C99's "restrict", combined with C89 "const", *does* make promises
    like this, and can allow additional optimization. I believe
    optimization was the main, or perhaps even sole, motivation for
    adding "restrict".)

    >There is no need to modify your code.


    This is of course true. :)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 14, 2007
    #7
    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. Mark van Heeswijk

    copying strings efficiently?

    Mark van Heeswijk, Aug 29, 2003, in forum: C++
    Replies:
    3
    Views:
    366
    John Harrison
    Aug 31, 2003
  2. Lafer

    problems with copying/editing strings

    Lafer, Feb 18, 2004, in forum: C Programming
    Replies:
    4
    Views:
    552
    Joona I Palaste
    Feb 19, 2004
  3. Ben

    Strings, Strings and Damned Strings

    Ben, Jun 22, 2006, in forum: C Programming
    Replies:
    14
    Views:
    732
    Malcolm
    Jun 24, 2006
  4. Angus

    confused about copying strings

    Angus, Jul 17, 2010, in forum: C Programming
    Replies:
    4
    Views:
    273
    Thomas Jollans
    Jul 18, 2010
  5. WoodHacker

    Copying strings

    WoodHacker, Jan 19, 2007, in forum: Ruby
    Replies:
    3
    Views:
    84
    WoodHacker
    Jan 19, 2007
Loading...

Share This Page