> Example: you pass an object by value, and only read one field, can it optimize this?

Yes.

    struct S { int a,b; };
    void foo(int); // Some external function
    void bar(S s) { foo(s.a); }
    void baz() { bar(S{42, 55}); }

compiles the baz function to (-O2 on GCC 4.9)

    movl    $42, %edi
    jmp     _Z3fooi

Copying short non-overlapping chunks of memory is common in a lot of workloads (think manipulation of short strings) and it does happen in tight loops where an overlap check with two additions, two comparisons and two branches is a comparable amount of work to what memcpy() does.

Why should I have to manually implement memcpy() for small sizes when I know the memory won't overlap?

I see they've finally changed the memcpy() specification to forbid overlapping memory areas completely.

Previously, it was defined to copy from low addresses to high addresses, which meant you could use this to fill an array:

    p[0] = 42;
    memcpy(&p[1], &p[0], sizeof(p)-sizeof(*p));

And people did.

The original 1989 ANSI C specification stated, in "4.11.2.1 The memcpy function":

If copying takes place between objects that overlap, the behavior is undefined.

So it has been this way in C since the first official standard. I don't have a first edition K&R so I can't see what that said, though.

Huh. You're quite right.

Well, it may have been undefined, but in practice the behaviour was standardised and couldn't be changed without breaking existing code... which is basically C in a nutshell.

Code like your example would have been broken by real standard library implementations very early in the piece, because even a forward-copying implementation that does word-at-a-time copies (a straightforward and obvious optimisation with real and significant benefits on many machines of the era) would have broken it.

> The real question is: why are there two versions?

Because long long ago, when CPU was slow, and compiler and stdlib were stupid, there were two versions.