Monday, November 22, 2010

memcpy, memmove, and overlapping regions

The C runtime library provides two similar-but-different functions:


The primary distinction between these two functions is that memmove handles situations where the two memory regions may overlap, while memcpy does not.

And the memcpy manual pages describe this quite clearly:

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


You might not think that is a very strong statement, but in C programming, when somebody says "the behavior is undefined", this is an extremely strong thing to say; here's a few articles that try to explain what we mean when we say "the behavior is undefined", but the bottom line is: if you program in C, you need to sensitize yourself to the phrase "undefined behavior" and not write programs which perform an action which has undefined behavior.

However, it so happens that, although memcpy has contained this statement forever (well, in programming terms at least!), one of the most common memcpy implementations, has until recently been implemented in a way which caused it to be safe, in practice, to call memcpy with overlapping memory regions.

But things have changed: https://bugzilla.redhat.com/show_bug.cgi?id=638477 There's a lot of interesting discussion in that bug report, but let me particularly draw your attention to Comment 31 and to Comment 38, and to Comment 46. Suffice it to say that the author of those comments knows a little bit about writing system software, and probably has some useful suggestions to offer :)

Happily, as several of the other comments note, the wonderful (though oddly-named) valgrind tool does a quite reasonable job of detecting invalid uses of memcpy, so if you're concerned that you might be encountering this problem, let valgrind have a spin over your code and see what it finds.

1 comment:

  1. I love this. If I were Andreas I would be hiding somewhere for a while. I also like how Linus gives example code using 'cat >' showing he is a wizard in the unix hierarchy.

    ReplyDelete