(newbie)Technically what's the difference between memset() andmemcpy() functions?

[sam]

(newbie)Technically what's the difference between memset() and
memcpy() functions?

 

[Bart Friederichs]

(newbie)Technically what's the difference between memset() and
memcpy() functions?

You could read the manual ...

memset() sets a memory area to a certain value
memcpy() copies one memory area to another area

Bart

 

[Road.Tang]

(newbie)Technically what's the difference between memset() and
memcpy() functions?

just as the naming of the funcation.

memset is used to *set* a range of memory to the unique value.

#define BUFSIZE 1024
char buf[BUFSIZE];
memset(buf, 0, sizeof(BUFSIZE)); /* set [buf, buf+BUFSIZE) range
memory to 0 */

whereas, memcpy is used to *copy* a range of memory into another
range of memory.

char buf1[BUFSIZE];
char buf2[BUFSIZE] = { 'a', 'b', 'c' };

memcpy(buf1, buf2, sizeof(buf2)); /* copy the value of buf2 into buf1
*/

Roadt

 

[James Kanze]

(newbie)Technically what's the difference between memset() and
memcpy() functions?

Well, formally, they do different things. Practically, who
cares? You'd never use either in a C++ program.

 

[red floyd]

Well, formally, they do different things.  Practically, who
cares?  You'd never use either in a C++ program.

Not necessarily. If you are using a library with a C API, and they
require a zeroed POD struct as a param, memset is your easiest bet.

 

[gw7rib]

(newbie)Technically what's the difference between memset() and
memcpy() functions?

A more interesting question would be - what's the difference between
memcpy() and memmove()?

The answer to this one is that memcpy can go wrong if the place it's
moving from and the place it's moving to overlap. As a simple example,
suppose you ask it to copy 20 bytes from addresses [100-119] to
addresses [105-124]. It might copy the contents of [100] to [105],
then the contents of [101] to [106], etc, but when it gets to [105],
instead of copying what was originally in [105], this has already been
overwritten and so what it reads, and copies to [110], is what was
originally in [100]. So instead of getting a copy of what was in
[100-119], you get four copies of what was in [100-105].

memmove() is guaranteed not to go wrong in this way.

Hope that helps.
Paul.

 

[James Kanze]

Not necessarily. If you are using a library with a C API, and
they require a zeroed POD struct as a param, memset is your
easiest bet.

The problem is that memset doesn't necessarily zero the
structure correctly. The correct solution to the above (even in
C) is to declare a static instance of the struct, and assign it
to the struct you want to zero.

 

[Gennaro Prota]

Read about structure initialisation and remove all these pointless
memset from your code. For example:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=171

Please, don't link to articles with such low quality. I did read up to sixth
line (excluding titles) and there were more technical errors than words.

 

[Default User]

Strictly speaking, memcpy did not go wrong. It did exactly what was
asked for which is copy byte by byte 20 bytes from address 100 to
address 105.

No, strictly speaking, use of memcpy() with overlapping objects is
undefined behavior. There is no defined behavior for undefined
behavior, so you can't call any particular behavior "right" or "wrong".




Brian

 

[James Kanze]

Is it acceptable to do this:

Foo x = { 0 };

assuming Foo is a POD struct.

Or even:
Foo x = {} ;
if you need a variable. In C++ (but not in C), it's also
possible to write Foo() to obtain a zero initialized temporary
of type Foo.

In fact, my suggestion is somewhat dated, going back to the time
when I was programming in C (which was before C90, when some
compilers didn't allow agglomerate initialization for local
variables).

 

[Nick Keighley]

That part of my comment was a bit tongue in cheek.


Sorry, this is not undefined behaviour with memcpy().

yes it is. This is a *direct quote* from The Standard [1]

"If copying takes place objects that overlap, the behavior is
undefined"

memcpy()
doesn't care if you try to copy overlapping POD array or C++ objects
overlapping. memcpy() only works with bytes, it is not concerned
about wether these bytes represent an object or a char[] nor if the
destination overlaps with the source, it just does it exactly as
instructed. There result is perfectly defined and predictable. No
undefined behaviour there.

that's not what the standard says.

However, if you use memcpy to copy an object partly overlapping over
itself, then you are corrupting memory. Attempting to use this
corrupted memory as a C++ object is undefined behaviour.

Essentially, what you are doing is taking the (void *) which is the
output of the memcpy and casting it to a class type. This is
undefined behaviour if the (void *) did not point to a object of the
class in the first place.

[1] I'm quoting the ANSI *C* standard, because I had it handy.
I'm assuming C++ has not chnaged in this area.

 

[James Kanze]

[...]

yes it is. This is a *direct quote* from The Standard [1]

"If copying takes place objects that overlap, the behavior is
undefined"

[...]

[1] I'm quoting the ANSI *C* standard, because I had it handy.
I'm assuming C++ has not chnaged in this area.

The C++ simply says that memcpy has the signature and the
behavior described in Standard C.