Disagreement about memcpy

Me and some other co-students we have a disagreement on checking the result of memcpy.
Based on these references
www.elook.org
www.cplusplus.com

some of us believe that one can't check if memcpy failed unless if after use it, compare using memcmp the destination with source.
ex :

Code:

---

  memcpy(dest,source,Size);
  if(memcmp(dest,source,Size) != 0)
      puts("Memcpy failed");

---

Some other co-students believe that one can check if memcpy fail by comparing the return value with NULL.
ex.

Code:

---

  if(memcpy(dest,source,Size) == NULL)
    puts("Memcpy failed");

---

*Supose that dest/source/Size are valid

Finally i also think that there is no point on check memcpy as far as i pass valid arguments.
Precaution is better than treatment !!!

We need an opinion here :)

You're both wrong. You can't "check" the result of a memcpy.
It's like adding 1 + 1. You don't "check" if the result is 2. The result simply is 2.

You're not allowed to pass invalid arguments to memcpy - ever! If there's any checking to be done, it's that the pointers passed in must be valid and to sufficiently sized areas of memory beforeeven deciding to call memcpy.

Or to put it another way, you don't drive through a red light at a busy intersection, and then check if there were no cars coming.

In truth, memcpy can not fail [obviously assuming correctly working hardware and not wacky arguments and it tries to read/write memory that it shouldn't be touching and source and destination are not overlapping, and that it's a proper memcpy function, rather than someones school project with bugs in it (although a trivial version of memcpy could be written in about 3 lines of actual code)].

memcpy() ALWAYS returns the destination address - checking that for null is pretty meaningless, as any modern system would crash before returning.

--
Mats

Quote:

---

some of us believe that one can't check if memcpy failed unless if after use it, compare using memcmp the destination with source.

---

If you were to believe that, shouldn't you also test whether memcmp failed? :)

Quote:

---

Originally Posted by anon

If you were to believe that, shouldn't you also test whether memcmp failed? :)

---

I've checked it for non valid arguments.


Personally i don't think that memcpy fails if arguments are fine.

Thank you all.

The only manner in which memcpy() can fail is by crashing your program.

You can still use memcpy() improperly, by passing pointers to invalid areas, or pointers to areas which aren't big enough, but the result will either be a successful copy (silently corrupting memory) or a crash.

The return value of memcpy() is academic.

Technically, memcpy shouldn't even fail if there is not a great failure in you system or you aren't allowed to read/write memory to those locations.

Quote:

---

Originally Posted by Brafil

Technically, memcpy shouldn't even fail if there is not a great failure in you system or you aren't allowed to read/write memory to those locations.

---

That obviously depends on the definition of "fail" - but indeed, as long as the destination memory is writable, and the source memory is readable for the entire size, then it will complete the memcpy().

Bad things will happen if you in the process overwrite for example the stack, or some other critical data. That's not a "memcpy() failed", but generally "the program failed".

Simply put, memcpy() doesn't fail. It may crash the application if you write outside valid memory, and it may crash the application if data is written to the wrong location.

It is also undefined what happens if you have overlapping regions. Again, memcpy() doesn't even try to detect this, it just copies the source data to the destination data. The fact that this (maybe) overwrites some of the source data before the source data has been copied is "bad usage of memcpy", and not considered memcpy failing in a direct way - but it's obviously resulting in "incorrect data" (and memcmp() would detect this).

--
Mats

Quote:

---

Originally Posted by matsp

Bad things will happen if you in the process overwrite for example the stack, or some other critical data. That's not a "memcpy() failed", but generally "the program failed".

---

Or, probably much more common: "the programmer failed"

Damn matsp, I am about to write down my thoughts on this and you nail it before me.

The issue is not if memcpy() will fail or not, it is in how it is being used. "You give a programmer enough rope to do this and that: pointers, function pointers, memcpy(), and sometimes they hang themselves!"