应该始终使用memcpy吗？

Question

I was working with C and manual memory management and playing around with my code and I noticed this:

Suppose I had

int *a = malloc(sizeof(int));
int *b = malloc(sizeof(int));
int c = 10;

If I take these numbers and do this:

*a = c;

Then a will point to a distinct location in memory separate from c but will have the value of c . If I used:

memcpy(a, &c, sizeof(int)); 

The same thing would happen. Distinct pointer, same value.

My question is whether one is preferable to the other? I know for char * usually it is memcpy or strcpy that is used but what about for ints? What about pointers in general? Is assignment ever ok?

PS I also know that

a = &c;

will make a point to the same memory location as c and therefore have its value but I would imagine that would leave a hanging pointer where a was since free is never called on the memory for a so I wouldn't use that.

Answer 1

In your example, you should use *a = c; since you only want to copy a single value. Use memcpy , if you need to copy several consecutive elements of an array.

Answer 2

It is implementation specific. Some compilers, including GCC , are able to optimize quite well (with gcc -O2 at least), calls to standard functions memcpy and to memset (which, as my former colleague Pascal Cuoq commented, may be inlined to efficient assignment machine code); sometimes, GCC is even able to optimize some assignment to some structures as calls to memcpy (sometimes, calling an efficient memcpy routine is faster for large enough struct , including for structure assignment; at other occasions, the call to memcpy , transformed via some __builtin_memcpy , is inlined as an efficient assignment code, perhaps even going thru registers without using any memory)

You could compile your foo.c example with gcc -fverbose-asm -O2 -march=native -S foo.c then look into the generated foo.s

So if you use a recent GCC or Clang/LLVM compiler (or some other good compiler) with optimizations enabled , you should use memcpy and memset ...

In other words, memcpy(a, &c, sizeof(int)); can be optimized as efficiently as *a = c; (and if you define a "type generic" macro eg using _Generic from C99, you would use memcpy and it should be optimized efficiently).

Answer 3

Should memcpy always be used?

Plain and simple, no .

Your first goal in writing code is to make it understandable and maintainable. Everyone knows what *a = c will do when a is declared as a pointer to an int and c is declared as an int. The compiler also knows exactly what you mean by that. You'll never see a compiler optimize your *a = c to a call to memcpy because that would be a disoptimization.

You will see the compiler optimize *a=c to a call to memcpy when c is of type struct AVeryLargeStruct and a is a pointer to the same. There's no need to convert *a=c to memcpy(a,&c, sizeof(c)) because the compiler does that for you, a gratis . Write *a=c because that is clearer than and less error prone than is the memcpy .

There are a few places where you truly do need to use memcpy (or memmove ):

• Copying an array,
• Type punning, without using unions, and
• Copying to or from improperly aligned memory.

The first is standard operating procedure; no one will be shocked on reading your code and seeing a call to memcpy when used in that context. The latter two are not SOP. Usages of memcpy in that context will give readers of your code pause. That's a good thing because you are doing something a bit tricky there. Hiding those tricky calls to memcpy amongst thousands of other calls to memcpy where you could have used ordinary assignment makes those few places where you absolutely do need to use memcpy not stand out. That's a good thing only if your goal is to win the IOCCC.

If you use memcpy everywhere you are likely to make your code slower and you are even more likely to make others think there's something wrong with your code.