Questions about memmove

[Michael Wojcik]

Or, if you'd like another opinion: don't. memcpy has little
advantage over structure assignment except for a dubious one of
documentation (but see below); and it may well have performance
disadvantages in many circumstances.

One possible argument for using memcpy in certain cases is that it
creates a bit-for-bit identical copy, whereas structure assignment is
free to skip padding bytes. Should you later decide to use memcmp to
compare the original structure and its copy, structure assignment
could produce a copy that will compare unequal even though all
members of the two structures are equal. C's lack of a structure
comparison operator aggravates this slightly.

However, I suspect it's rarely very useful to compare two structures
in their entirety, and memcmp seems like a very poor way to do that,
since it's only guaranteed to work in the case where one structure
was copied from the other with memcpy, and neither have been changed
since then. (And perhaps not even then; I haven't looked for cases
where they might still differ.) Comparing each member explicitly
looks much more sensible.

Personally I dislike the = operator applied to struct
assignments, since it fails to make clear that this may be an expensive
operation. To people used to other languages, it also fails to make it
obvious that this is a "shallow copy".

[...]
Long long ago, my program failed to read consecutive disk sectors without
"slipping a rev"; there was a lot of cache-checking code, etc. but the
culprit was just an innocuous-looking " sector %= secs_per_trk; "
Obviously I would have noticed and fixed this computational bottleneck
much sooner if the / and % operators were replaced with
"do_a_time_consuming_divide()"

There's always COBOL, if you want to spell everything out.

C is terse. That's a characteristic of the language. Attempting to
avoid that terseness in a few particular cases, as Malcolm recommends
with memcpy versus structure assignment, strikes me as a fool's
errand. If you're worried that your code may be unclear, add
comments. (And if it's at all likely that someone unfamiliar with C
will be maintaining your code, you have worse problems than their
mistaking the "depth" of C's structure assignment operator.)

--
Michael Wojcik (e-mail address removed)

An intense imaginative activity accompanied by a psychological and moral
passivity is bound eventually to result in a curbing of the growth to
maturity and in consequent artistic repetitiveness and stultification.
-- D. S. Savage

 

[Flash Gordon]

Agreed, and this could be relevant if you later try to compare the
structures using memcmp().

Agreed. However, I wouldn't use memcmp on a structure for the reason we
both know, i.e. you are only guaranteed to get equality if the last
write was the memcpy.

The compiler is more likely to be able to do clever tricks with an
assignment than with memmove/memcpy, but since they're part of the
standard library the compiler could still do clever tricks even with
the function calls.

Indeed. In fact, due to the difficulty of doing clever things with
structures and the simplicity of inlining and potentially optimising
memcpy calls I would not be surprised if the compiler implemented the
assignment as a memcpy.

An assignment could also be implemented as a function call.

The smarter the compiler, the less difference there is (at least
potentially) between memcpy() and assignment.

Agreed. I would generally use assignment because it is less typing.