By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,496 Members | 1,489 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,496 IT Pros & Developers. It's quick & easy.

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

P: n/a
sam
(newbie)Technically what's the difference between memset() and
memcpy() functions?
Sep 10 '08 #1
Share this Question
Share on Google+
18 Replies


P: n/a
sam wrote:
(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
Sep 10 '08 #2

P: n/a
On Sep 10, 8:59*pm, sam <sameer...@gmail.comwrote:
(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
Sep 10 '08 #3

P: n/a
On Sep 10, 2:59 pm, sam <sameer...@gmail.comwrote:
(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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 10 '08 #4

P: n/a
On Sep 10, 9:34*am, James Kanze <james.ka...@gmail.comwrote:
On Sep 10, 2:59 pm, sam <sameer...@gmail.comwrote:
(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.
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.
Sep 10 '08 #5

P: n/a
On 10 Sep, 13:59, sam <sameer...@gmail.comwrote:
(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.
Sep 10 '08 #6

P: n/a
On Sep 10, 10:20 pm, red floyd <redfl...@gmail.comwrote:
On Sep 10, 9:34 am, James Kanze <james.ka...@gmail.comwrote:
On Sep 10, 2:59 pm, sam <sameer...@gmail.comwrote:
(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.
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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 11 '08 #7

P: n/a
In article <a1**********************************@r66g2000hsg. googlegroups.com>,
red floyd <re******@gmail.comwrote:
>On Sep 10, 9:34*am, James Kanze <james.ka...@gmail.comwrote:
>On Sep 10, 2:59 pm, sam <sameer...@gmail.comwrote:
(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.

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

Have you tried:

struct MyPodStruct; // define it somewhere
MyPodStruct s = {0};
Read about structure initialisation and remove all these pointless
memset from your code. For example:
http://www.informit.com/guides/conte...lus&seqNum=171

I think you can also do

MyPodStruct s = {};

but I seem to be unable to find precise information if there is a
difference between the two and I don't have access to the standard at
the moment. I don't think so since if there are too few initialisers,
the remaining are assumed to be 0. Anyone?

Yannick


Sep 11 '08 #8

P: n/a
In article <6a**********************************@r66g2000hsg. googlegroups.com>,
<gw****@aol.comwrote:
>On 10 Sep, 13:59, sam <sameer...@gmail.comwrote:
>(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.
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.

I would hesitate to recommend using memmove over memcpy in the general
case based on being resilient to this programming mistake because one
of the only justification to use memcpy is its efficiency. By virtue
of protecting against the above case, memmove has to be less efficient
than memcpy. Obviously, in 95% of cases you won't care about
efficiency so should use neither memcpy nor memmove but stick with
much safer things like copy constructors, assigment operator,
std::swap and std::copy.
Yannick
Sep 11 '08 #9

P: n/a
Yannick Tremblay wrote:
Read about structure initialisation and remove all these pointless
memset from your code. For example:
http://www.informit.com/guides/conte...lus&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.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.
Sep 11 '08 #10

P: n/a
In article <ga**********@aioe.org>,
Gennaro Prota <gennaro/pr***@yahoo.comwrote:
>Yannick Tremblay wrote:
>Read about structure initialisation and remove all these pointless
memset from your code. For example:
<censored URL not to raise more issues>

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.
I'll confess not to having read the introduction paragraph properly.
He seems to confuse objects, variables. types and POD, so yeah, not
fantastic. I just googled for an article to elaborate on the
subject and I guess I should not have. The code samples below are
not that bad. really :-(
However, the main point of my comment remain valid:
One should not:
---------------------------
struct MyStruct;

MyStruct s;
memset(&s, 0, sizeof(s));
---------------------------

But should simply do:
-------------------------
struct MyStruct;

MyStruct s = {};
-------------------------
Yan

Sep 11 '08 #11

P: n/a
Yannick Tremblay wrote:
In article
<6a**********************************@r66g2000hsg. googlegroups.com>,
<gw****@aol.comwrote: >On 10 Sep, 13:59, sam <sameer...@gmail.com>
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.
memmove() is guaranteed not to go wrong in this way.

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
Sep 11 '08 #12

P: n/a
James Kanze wrote:
On Sep 10, 10:20 pm, red floyd wrote:
>On Sep 10, 9:34 am, James Kanze wrote:
On Sep 10, 2:59 pm, sam wrote:
(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.
>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.
Is it acceptable to do this:

Foo x = { 0 };

assuming Foo is a POD struct.
--
Fran
Sep 12 '08 #13

P: n/a
On Sep 12, 3:07 am, Francis Litterio <em...@not.availablewrote:
James Kanze wrote:
On Sep 10, 10:20 pm, red floyd wrote:
On Sep 10, 9:34 am, James Kanze wrote:
On Sep 10, 2:59 pm, sam wrote:
(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.
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.
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).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 12 '08 #14

P: n/a
In article <6i***********@mid.individual.net>,
Default User <de***********@yahoo.comwrote:
>Yannick Tremblay wrote:
>In article
<6a**********************************@r66g2000hsg .googlegroups.com>,
<gw****@aol.comwrote: >On 10 Sep, 13:59, sam <sameer...@gmail.com>
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.
memmove() is guaranteed not to go wrong in this way.

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.
That part of my comment was a bit tongue in cheek. :-)
>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".
Sorry, this is not undefined behaviour with memcpy(). 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.

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.

Yannick

Sep 12 '08 #15

P: n/a
On 12 Sep, 09:57, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <6it6c9Fee8...@mid.individual.net>,
Default User <defaultuse...@yahoo.comwrote:
Yannick Tremblay wrote:
In article
<6adede5b-beec-41f7-9218-cdfc62319...@r66g2000hsg.googlegroups.com>,
<gw7...@aol.comwrote: >On 10 Sep, 13:59, sam <sameer...@gmail.com>
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.
memmove() is guaranteed not to go wrong in this way.
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.

That part of my comment was a bit tongue in cheek. :-)
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".

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.

--
Nick Keighley
Sep 12 '08 #16

P: n/a
On Sep 12, 12:29 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 12 Sep, 09:57, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <6it6c9Fee8...@mid.individual.net>,
Default User <defaultuse...@yahoo.comwrote:
[...]
>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.
That part of my comment was a bit tongue in cheek. :-)
>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".
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"
[...]
[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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sep 12 '08 #17

P: n/a
James Kanze wrote:
On Sep 12, 12:29 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>On 12 Sep, 09:57, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <6it6c9Fee8...@mid.individual.net>,
Default User <defaultuse...@yahoo.comwrote:

[...]
>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.
That part of my comment was a bit tongue in cheek. :-)
>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".
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"

[...]
>[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.
I always thought C required nasal demons while C++ being newer preferred
something more exotic. I guess I need a non-redlined^h^h^h^h^h newer copy of
the standard :)
Sep 12 '08 #18

P: n/a
In article <6f**********************************@k7g2000hsd.g ooglegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:
>On 12 Sep, 09:57, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
>In article <6it6c9Fee8...@mid.individual.net>,
Default User <defaultuse...@yahoo.comwrote:
>Yannick Tremblay wrote:
In article
<6adede5b-beec-41f7-9218-cdfc62319...@r66g2000hsg.googlegroups.com>,
<gw7...@aol.comwrote: >On 10 Sep, 13:59, sam <sameer...@gmail.com>
>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".

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"
Sorry about that , my manual simply stated: "The memory areas should
not overlap" rather than "must not".

Thanks for the correction.

Yannick
Sep 17 '08 #19

This discussion thread is closed

Replies have been disabled for this discussion.