Disagreement about memcpy

This is a discussion on Disagreement about memcpy within the C Programming forums, part of the General Programming Boards category; Me and some other co-students we have a disagreement on checking the result of memcpy. Based on these references www.elook.org ...

  1. #1
    ch4
    ch4 is offline
    Newbeer ch4's Avatar
    Join Date
    Jan 2007
    Posts
    142

    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

  2. #2
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,295
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  5. #5
    ch4
    ch4 is offline
    Newbeer ch4's Avatar
    Join Date
    Jan 2007
    Posts
    142
    Quote Originally Posted by anon View Post
    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.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,236
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    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.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Brafil View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    int x = *((int *) NULL); Cactus_Hugger's Avatar
    Join Date
    Jul 2003
    Location
    Banks of the River Styx
    Posts
    902
    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"
    long time; /* know C? */
    Unprecedented performance: Nothing ever ran this slow before.
    Any sufficiently advanced bug is indistinguishable from a feature.
    Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
    The best way to accelerate an IBM is at 9.8 m/s/s.
    recursion (re - cur' - zhun) n. 1. (see recursion)

  10. #10
    Registered User slingerland3g's Avatar
    Join Date
    Jan 2008
    Location
    Seattle
    Posts
    602
    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!"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 14
    Last Post: 06-28-2006, 01:58 AM
  2. Memcpy(); Errors...
    By Shamino in forum C++ Programming
    Replies: 4
    Last Post: 03-24-2006, 10:35 AM
  3. memcpy with 128 bit registers
    By grady in forum Linux Programming
    Replies: 2
    Last Post: 01-19-2004, 05:25 AM
  4. Trying to copy buffers using memcpy in C under UNIX
    By Meeper in forum C Programming
    Replies: 3
    Last Post: 07-26-2003, 08:51 AM
  5. memcpy
    By doubleanti in forum C++ Programming
    Replies: 10
    Last Post: 02-28-2002, 03:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21