Question: I know I can just copy the function by reference, but I want to understand what's going on in the following code that produces a segfault.

```
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int return0()
{
    return 0;
}

int main()
{
    int (*r0c)(void) = malloc(100);
    memcpy(r0c, return0, 100);
    printf("Address of r0c is: %x\n", r0c);
    printf("copied is: %d\n", (*r0c)());
    return 0;
}

```

Here's my mental model of what I thought should work.

The process owns the memory allocated to r0c. We are copying the data from the data segment corresponding to return0, and the copy is successful.

I thought that dereferencing a function pointer is the same as calling the data segment that the function pointer points to. If that's the case, then the instruction pointer should move to the data segment corresponding to r0c, which will contain the instructions for function return0. The binary code corresponding to return0 doesn't contain any jumps or function calls that would depend on the address of return0, so it should just return 0 and restore ip... 100 bytes is certainly enough for the function pointer, and 0xc3 is well within the bounds of r0c (it is at byte 11).

So why the segmentation fault? Is this a misunderstanding of the semantics of C's function pointers or is there some security feature that prevents self-modifying code that I'm unaware of?

Answer: 
The memory pages used by `malloc` to allocate memory are not marked as executable. You can't copy code to the heap and expect it to run.

If you want to do something like that you have to go deeper into the operating system, and allocate pages yourself. Then you need to mark those as executable. You would most likely need administrator rights to be able to set the executable flag on memory pages.

And it's really dangerous. If you do this in a program you distribute and have some kind of bug that lets an attacker use our program to write to those allocated memory pages, then the attacker can gain administrator rights and take control of the computer.

---

There's also other problems with your code, like pointers to functions might not translate well into general pointers on all platforms. It's very hard (not to mention non-standard) to predict or otherwise get the size of a function. You also print out pointers wrong in your code example. (use the `"%p"` format to print a `void *`, casting the pointer to a `void *` is needed).

Also when you declare a function like `int fun()` that's not the same as declaring a function that takes no arguments. If you want to declare a function that takes no arguments you should explicitly use `void` as in `int fun(void)`.
The standard says:

> 
> The `memcpy` function copies `n` characters from the ***object*** pointed to by `s2` into the object pointed to by `s1`.
> 
> 
> 

[C2011, 7.24.2.1/2; emphasis added]

In the standard's terminology, functions are not "objects". The standard does not define behavior for the case where the source pointer points to a function, therefore such a `memcpy()` call produces undefined behavior.

Additionally, the pointer returned by `malloc()` is an object pointer. C does not provide for direct conversion of object pointers to function pointers, and it does not provide for objects to be called as functions. It is possible to convert between object pointer and function pointer by means of an intermediate integer value, but the effect of doing so is at minimum doubly implementation-defined. Under some circumstances it is undefined.

As in other cases, UB can turn out to be precisely the behavior you hoped for, but it is not safe to rely on that. In this particular case, other answers present good reasons to *not* expect to get the behavior you hoped for.