Re: memcopy, memmove Implementation

Discussion in 'C Programming' started by Dan Pop, Jun 24, 2003.

  1. Dan Pop

    Dan Pop Guest

    In <> pete <> writes:

    >Richard Heathfield wrote:
    >
    >> So yes, the object pointed to by bar is indeed changed by memmove,
    >> despite the const. BUT of course the behaviour is still well-defined,
    >> because at no point is memmove having to write to anything
    >> other than a modifiable lvalue.

    >
    >Even if the s2 parameter, were not const qualified,
    >there is still enough information in the standard
    >to make the determination that
    >
    > memcpy(s1, "source", sizeof "source")
    >
    >is a valid call, assuming only that s1 points to
    >something writeable and big enough.
    >That means there's also enough information in the standard
    >to let the implementor of memcpy() know that
    >memcpy() has to be able to handle a call like that.


    The const in the declaration of s2 serves a completely different
    purpose. Consider the slightly modified version of your call:

    memcpy(s1, (const char *)"source", sizeof "source")

    If s2 were not const qualified, such code would require a diagnostic,
    because the const would be lost when converting the second argument of
    the memcpy call to the type of s2.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jun 24, 2003
    #1
    1. Advertisements

  2. Dan Pop

    pete Guest

    Dan Pop wrote:
    >
    > In <> pete <> writes:
    >
    > >Richard Heathfield wrote:
    > >
    > >> So yes, the object pointed to by bar is indeed changed by memmove,
    > >> despite the const.
    > >> BUT of course the behaviour is still well-defined,
    > >> because at no point is memmove having to write to anything
    > >> other than a modifiable lvalue.

    > >
    > >Even if the s2 parameter, were not const qualified,
    > >there is still enough information in the standard
    > >to make the determination that
    > >
    > > memcpy(s1, "source", sizeof "source")
    > >
    > >is a valid call, assuming only that s1 points to
    > >something writeable and big enough.
    > >That means there's also enough information in the standard
    > >to let the implementor of memcpy() know that
    > >memcpy() has to be able to handle a call like that.

    >
    > The const in the declaration of s2 serves a completely different
    > purpose. Consider the slightly modified version of your call:
    >
    > memcpy(s1, (const char *)"source", sizeof "source")
    >
    > If s2 were not const qualified, such code would require a diagnostic,
    > because the const would be lost when converting the second argument of
    > the memcpy call to the type of s2.


    OK.

    --
    pete
     
    pete, Jun 24, 2003
    #2
    1. Advertisements

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. Replies:
    2
    Views:
    11,570
    Gianni Mariani
    Feb 14, 2005
  2. ROSY

    diff between memmove & memecpy

    ROSY, Sep 17, 2003, in forum: C Programming
    Replies:
    65
    Views:
    1,713
    Mike Wahler
    Oct 5, 2003
  3. Mike Wahler

    resolved: difference between memcpy and memmove

    Mike Wahler, Sep 27, 2003, in forum: C Programming
    Replies:
    21
    Views:
    1,725
    Jirka Klaue
    Sep 30, 2003
  4. Christopher Benson-Manica

    memcpy/memmove

    Christopher Benson-Manica, Nov 12, 2003, in forum: C Programming
    Replies:
    39
    Views:
    1,463
    Dan Pop
    Nov 20, 2003
  5. niko

    memmove() loses bits...

    niko, Jun 12, 2004, in forum: C Programming
    Replies:
    5
    Views:
    401
    Arthur J. O'Dwyer
    Jun 13, 2004
  6. kyo guan
    Replies:
    1
    Views:
    328
    John Machin
    Apr 30, 2006
  7. Replies:
    15
    Views:
    830
    Jorgen Grahn
    Feb 1, 2007
  8. JeanDean
    Replies:
    2
    Views:
    469
    Grizlyk
    Feb 13, 2007
Loading...