Doubt in memcpy() and memset()

Discussion in 'C Programming' started by Shhnwz.a, Dec 6, 2006.

  1. Shhnwz.a

    Shhnwz.a Guest

    Hi,
    I want to know some of the situations , when to use memcpy() and when
    to memset();

    Thanx in Advance..
    Shhnwz.a, Dec 6, 2006
    #1
    1. Advertising

  2. Shhnwz.a

    Tom St Denis Guest

    Shhnwz.a wrote:
    > Hi,
    > I want to know some of the situations , when to use memcpy() and when
    > to memset();
    >
    > Thanx in Advance..


    NAME
    memcpy - copy memory area

    NAME
    memset - fill memory with a constant byte

    HOMEWORKALITY!

    [hint: man pages are fun]

    Tom
    Tom St Denis, Dec 6, 2006
    #2
    1. Advertising

  3. Shhnwz.a

    Chris Dollin Guest

    Shhnwz.a wrote:

    > I want to know some of the situations , when to use memcpy() and when
    > to memset();


    Can't you tell from their descriptions?

    memcpy( void *s1, const void *s2, size_t n );

    ... copies n characters from the object pointed to by s2
    into the object pointed to by s1. If copying takes place
    between objects that overlap, the behaviour is undefined.

    memset( void *s, int c, size_t n );

    ... copies the value of c (converted to an unsigned char)
    into each of the first n characters of the object pointed
    to by s.

    Use whichever one fits your situation.

    --
    Chris "Perikles triumphant" Dollin
    "No-one here is exactly what he appears." G'kar, /Babylon 5/
    Chris Dollin, Dec 6, 2006
    #3
  4. Shhnwz.a

    Dead Loop Guest

    Chris Dollin wrote:
    >
    > memset( void *s, int c, size_t n );
    >
    > ... copies the value of c (converted to an unsigned char)
    > into each of the first n characters of the object pointed
    > to by s.
    >


    By the way, I'm puzzled about the type of the second parameter.
    Why not use (unsigned char) type?
    memset(void *s, unsigned char c, size_t n);

    Thanks.
    Dead Loop, Dec 6, 2006
    #4
  5. Shhnwz.a

    Lew Pitcher Guest

    Dead Loop wrote:
    > Chris Dollin wrote:
    > >
    > > memset( void *s, int c, size_t n );
    > >
    > > ... copies the value of c (converted to an unsigned char)
    > > into each of the first n characters of the object pointed
    > > to by s.
    > >

    >
    > By the way, I'm puzzled about the type of the second parameter.
    > Why not use (unsigned char) type?
    > memset(void *s, unsigned char c, size_t n);


    Backwards compatibility.

    Both memcpy() and memset() were defined back in the day of K&R C. In
    the K&R C definition, char was automatically promoted to int when used
    as a function argument.
    Lew Pitcher, Dec 6, 2006
    #5
  6. Shhnwz.a

    Random832 Guest

    2006-12-06 <>,
    Lew Pitcher wrote:
    >
    > Dead Loop wrote:
    >> Chris Dollin wrote:
    >> >
    >> > memset( void *s, int c, size_t n );
    >> >
    >> > ... copies the value of c (converted to an unsigned char)
    >> > into each of the first n characters of the object pointed
    >> > to by s.
    >> >

    >>
    >> By the way, I'm puzzled about the type of the second parameter.
    >> Why not use (unsigned char) type?
    >> memset(void *s, unsigned char c, size_t n);

    >
    > Backwards compatibility.
    >
    > Both memcpy() and memset() were defined back in the day of K&R C. In
    > the K&R C definition, char was automatically promoted to int when used
    > as a function argument.


    yeah, but the size argument changed types. certainly nothing promotes to
    a size_t, and there's no guarantee that size_t doesn't promote to
    something.
    Random832, Dec 6, 2006
    #6
  7. Shhnwz.a

    Tom St Denis Guest

    Random832 wrote:
    > yeah, but the size argument changed types. certainly nothing promotes to
    > a size_t, and there's no guarantee that size_t doesn't promote to
    > something.


    Does it matter? Most platforms won't let you push a char on the stack
    anyways (disregarding the fact the standard makes no mention of
    "stack").

    So from a performance point of view it's moot.

    Tom
    Tom St Denis, Dec 6, 2006
    #7
  8. Tom St Denis wrote:
    >
    > Random832 wrote:
    > > yeah, but the size argument changed types. certainly nothing promotes to
    > > a size_t, and there's no guarantee that size_t doesn't promote to
    > > something.

    >
    > Does it matter? Most platforms won't let you push a char on the stack
    > anyways (disregarding the fact the standard makes no mention of
    > "stack").
    >
    > So from a performance point of view it's moot.


    No, but if you are passing an int rather than unsigned char, it
    may need to zero-fill the rest of the int before passing it.

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Dec 6, 2006
    #8
  9. Shhnwz.a

    Tom St Denis Guest

    Kenneth Brody wrote:
    > No, but if you are passing an int rather than unsigned char, it
    > may need to zero-fill the rest of the int before passing it.


    unsigned char x;
    int ix;

    x = 4;
    ix = x;

    What am I missing?

    totally legal conversion provided you keep the values in x to the
    portable range.

    Tom
    Tom St Denis, Dec 6, 2006
    #9
  10. "Tom St Denis" <> writes:
    > Kenneth Brody wrote:
    >> No, but if you are passing an int rather than unsigned char, it
    >> may need to zero-fill the rest of the int before passing it.

    >
    > unsigned char x;
    > int ix;
    >
    > x = 4;
    > ix = x;
    >
    > What am I missing?
    >
    > totally legal conversion provided you keep the values in x to the
    > portable range.


    Certainly it's legal. The question is performance (though in practice
    I don't think it's a significant concern).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Dec 6, 2006
    #10
  11. Tom St Denis wrote:
    >
    > Kenneth Brody wrote:
    > > No, but if you are passing an int rather than unsigned char, it
    > > may need to zero-fill the rest of the int before passing it.

    >
    > unsigned char x;
    > int ix;
    >
    > x = 4;
    > ix = x;
    >
    > What am I missing?
    >
    > totally legal conversion provided you keep the values in x to the
    > portable range.


    I may be mistaken here, but...

    extern void foo(unsigned char c);
    extern void bar(int i);

    void foobar()
    {
    unsigned char c = 'x';

    foo(c);
    bar(c);
    }

    Here, the call to foo() can push the single byte of c (if the system
    allows one to push a byte), or load the byte into a register and then
    push the register. However, the call to bar() requires that the byte
    be loaded into a register, while zero-filling the register prior to
    pushing it on the stack.

    Perhaps something like:

    load al,[c]
    push eax
    call foo

    xor eax,eax
    load al,[c]
    push eax
    call bar

    (Yes, this example assumes the concept of registers and a stack.)

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Dec 7, 2006
    #11
  12. Shhnwz.a

    CBFalconer Guest

    Kenneth Brody wrote:
    >

    .... snip ...
    >
    > Here, the call to foo() can push the single byte of c (if the system
    > allows one to push a byte), or load the byte into a register and then
    > push the register. However, the call to bar() requires that the byte
    > be loaded into a register, while zero-filling the register prior to
    > pushing it on the stack.


    There is no reason to assume the system has either registers or a
    stack. These are not specified in the C standard. In fact, I can
    think of systems that dispense with at least one of those concepts
    entirely, and handle C perfectly well.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Dec 8, 2006
    #12
  13. CBFalconer wrote:
    >
    > Kenneth Brody wrote:
    > >

    > ... snip ...
    > >
    > > Here, the call to foo() can push the single byte of c (if the system
    > > allows one to push a byte), or load the byte into a register and then
    > > push the register. However, the call to bar() requires that the byte
    > > be loaded into a register, while zero-filling the register prior to
    > > pushing it on the stack.

    >
    > There is no reason to assume the system has either registers or a
    > stack. These are not specified in the C standard. In fact, I can
    > think of systems that dispense with at least one of those concepts
    > entirely, and handle C perfectly well.


    Yes, I realize that. I was just using register-and-stack-based
    system as an example of the difference between passing an int and
    an unsigned char to a function, as noted in my last sentence:

    > (Yes, this example assumes the concept of registers and a stack.)


    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Dec 8, 2006
    #13
    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. srivatsan_b

    memset doubt

    srivatsan_b, Aug 31, 2005, in forum: C Programming
    Replies:
    22
    Views:
    1,004
    Keith Thompson
    Sep 4, 2005
  2. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    595
  3. Replies:
    0
    Views:
    539
  4. Peter Otten
    Replies:
    2
    Views:
    103
    Cousin Stanley
    Aug 10, 2013
  5. Terry Reedy
    Replies:
    0
    Views:
    106
    Terry Reedy
    Aug 10, 2013
Loading...

Share This Page