The only portable way to determine if two memory ranges overlap is:

int overlap_p(void *a, void *b, size_t n)
{
    char *x = a, *y =  b;
    for (i=0; i<n; i++) if (x+i==y || y+i==x) return 1;
    return 0;
}

This is because comparison of pointers with the relational operators is undefined unless they point into the same array. In reality, the comparison does work on most real-world implementations, so you could do something like:

int overlap_p(void *a, void *b, size_t n)
{
    char *x = a, *y =  b;
    return (x<=y && x+n>y) || (y<=x && y+n>x);
}

I hope I got that logic right; you should check it. You can simplify it even more if you want to assume you can take differences of arbitrary pointers.

I believe you mean memmove which takes care of memory overlapping as oppose to memset. but what is memory overlapping anyway?

suppose we have an array of 5 chars, where each char is a byte long

+++++++++++++++++++++++++++++++
| 'a' | 'b' | 'c' | 'd' | 'e' |
+++++++++++++++++++++++++++++++
 0x100 0x101 0x102 0x103 0x104

now according to the man page of memcpy, it takes 3 arguments, a pointer to the destination block of memory, a pointer to the source block of memory, and the size of bytes to be copied.

what if the destination is 0x102, the source is 0x100 and the size is 3? memory overlapping happens here. that is, 0x100 would be copied into 0x102, 0x101 would be copied into 0x103 and 0x102 would be copied into 0x104.

notice that we first copied into 0x102 then we copied from 0x102 which means that the value which was originally in 0x102 was lost as we overwrote it with the value we copied into 0x102 before we copy from it. so we would end up with something like

+++++++++++++++++++++++++++++++
| 'a' | 'b' | 'a' | 'b' | 'a' |
+++++++++++++++++++++++++++++++
 0x100 0x101 0x102 0x103 0x104

instead of

+++++++++++++++++++++++++++++++
| 'a' | 'b' | 'a' | 'b' | 'c' |
+++++++++++++++++++++++++++++++
 0x100 0x101 0x102 0x103 0x104

how does a function like memmove take care of memory overlapping? according to its man page, it first copies the bytes to be copied into a temporary array then pastes them into the destination block as oppose to a function like memcpy which copies directly from the source block to the destination block.

From the comments your problem is that you don't understand what "overlapping" means:

Overlapping means this:

Here the two memory regions src and dst do overlap:

But here they don't:

So if you have overlapping memory regions, then you cannot use memcpy but you have to use memmove.

Second question:

Yes, size_t is an unsigned integer type. The third argument is the number of bytes to copy, so it can hardly be anything else than an unsigned integer type.

I'm not entirely surprised that your example exhibits no strange behaviour. Try copying str1 to str1+2 instead and see what happens then. (May not actually make a difference, depends on compiler/libraries.)

In general, memcpy is implemented in a simple (but fast) manner. Simplistically, it just loops over the data (in order), copying from one location to the other. This can result in the source being overwritten while it's being read.

memmove does more work to ensure it handles the overlap correctly.

EDIT:

(Unfortunately, I can't find decent examples, but these will do). Compare the memcpy and memmove implementations shown here. memcpy just loops, while memmove performs a test to determine which direction to loop in to avoid corrupting the data. These implementations are rather simple. Most high-performance implementations are more complicated (involving copying word-size blocks at a time rather than bytes).

I've done some research on this in the past... on Linux, up until fairly recently, the implementation of memcpy() worked in a way that was similar enough to memmove() that overlapping memory wasn't an issue, and in my experience, other UNIXs were the same. This doesn't change the fact that this is undefined behavior according to the standard, and you are just lucky that on some platforms it sometimes works -- and memmove() is the standard-supported right answer.

However, in 2010, the glibc maintainers rolled out a new, optimized memcpy() that changed the behavior of memcpy() for some Intel core types where the C standard library is compiled to be faster, but no longer works like memmove() [1]. (I seem to recall also that this is new code triggered only for memory segments larger than 80 bytes). Interestingly, this caused things like the Linux version of Adobe's Flash player to break[2], as well as several other open-source packages (back in 2010 when Fedora Linux became the first to adopt the changed memcpy() in glibc).

• [1] https://sourceware.org/bugzilla/show_bug.cgi?id=12518
• [2] https://bugzilla.redhat.com/show_bug.cgi?id=638477

I'm trying to reproduce the behaviour of memcpy.

Bug: Wrong return value

When n == 0, memcpy() returns dest. OP's code should perform likewise.

// if (src == NULL || n == 0)
//        return (NULL);
if (src == NULL) // memcpy(..., NULL, ...) is not defined.  Do whatever you want.
  return NULL;  // or maybe `n = 0;`
if (n == 0) 
  return dest;

Bug: Insufficient space

With char buffer[] = "Overlap Test";, ft_memcpy(buffer + 3, buffer, strlen(buffer) + 1); is a problem as buffer + 3 does not have enough room for strlen(buffer) + 1 characters. @chqrlie

How is memcpy.c supposed to react to memory overlap?
Would such a result be expected in case of memory overlap?

Given the 2 restrict in the function signature, using overlapping buffers is undefined behavior (UB). There are no expected results.

void *memcpy(void * restrict s1, const void * restrict s2, size_t n);

Even if OP's ft_memcpy() functioned just like OP's compiler's memcpy() today, it is not certain it will tomorrow or on some other machine. It is UB.

I recommend to not test for equivalent functionality with overlapping buffers - since it is UB.
Notice, that focus on this issue missed proper behavior when n == 0.

Consider instead "How is memcpy.c memmove() supposed to react to memory overlap?"

That is trickier.

Copying takes place as if the n characters from the object pointed to by s2 are first copied into a temporary array of n characters that does not overlap the objects pointed to by s1 and s2, and then the n characters from the temporary array are copied into the object pointed to by s1.
C23dr § 7.26.2.3 2

OP's code needs changes to meet that. To do well is a challenge as the usual approach is to compare addresses. Depending on which is greater, copy from the beginning or end of the source buffer. Yet for user code, there is no defined way to compare arbitrary addresses for order. Various tricks abound that usually work.

The below does not have UB, yet may not compile nor function exactly like memmove() on all machines.

#include <stdlib.h>
#include <stdint.h>

void *ft_memmove(void *dst, const void *src, size_t n) {
  // Not needed as passing `NULL` for either pointer parameter is UB in memmove().
  if (dst == NULL || src == NULL) {
    n = 0;
  }
  // Weakness: uintptr_t is an optional type.
  uintptr_t d = (uintptr_t) dst;
  uintptr_t s = (uintptr_t) src;
  // Weakness: `d < s` is not a defined order compare of the pointers.
  if (d < s) {
    for (size_t i = 0; i < n; i++) {
      ((char*)dst)[i] = ((const char*)src)[i];
    }
  } else {
    while (n > 0) {
      n--;
      ((char*)dst)[n] = ((const char*)src)[n];
    }
  }
  return dst;
}