Doubt in memcpy() and memset()

[Shhnwz.a]

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

Thanx in Advance..

 

[Tom St Denis]

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

 

[Chris Dollin]

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.

 

[Dead Loop]

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.

 

[Lew Pitcher]

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.

 

[Random832]

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.

 

[Tom St Denis]

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

 

[Kenneth Brody]

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:[email protected]>

 

[Tom St Denis]

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

 

[Keith Thompson]

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).

 

[Kenneth Brody]

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:[email protected]>

 

[CBFalconer]

.... 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.

 

[Kenneth Brody]

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:[email protected]>