Posted Dec 1, 2010 5:19 UTC (Wed) by RogerOdle (subscriber, #60791)
Parent article: On breaking things
The documentation for memcpy says that memory regions should not overlap but who reads the documentation until something breaks? What should be done now? Considering how wide spread memcpy use is, this is not trivial. Who should determine what the memcpy functionality should be? At some point, enough people may use a function that inertia takes control away from the original writers. Should the writers change the functionality just to make it faster? What else could be done?
1. Go ahead and make the change. The problem is that memcpy works differently on different architectures. This is a bad thing. It results in portability problems.
2. Revert memcpy to they way it worked before and introduce new memcpy alternatives that are optimized. I would suggest one version for copying from higher-memory-to-lower (memcpyhl) and another for lower-memory-to-higher (memcpylh). The original memcpy may be modified so that it is safe for overlapped memory by selecting which optimised version to branch to. This would be compatible with existing applications and provide the faster algorithms for future applications.
3. Change the memcpy spec so that it says explicitly what way it will copy so that it can be made to work the same way on all architectures. This will not fix the current problem but, for the future, memcpy will always work the same way on every platform.
We have seen the effects the change has had on highly visible projects, it has surely effected many more projects. It is not enough to say that the writers had the right to make the change. They also have a responsibility to the people who trust that the behaviour of the library will be consistent. You have to be sensitive to the fact that the change will cost your users time and money. It is not a way to endear friends.