Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
If we want an optimised memcpy(), I think we should rather create a new memcpy_nooverlap() (feel free to find a better name) function which clearly states its nature.
Last but not least, if memcpy() had always _really_ been unsafe, we would not have the problem today,as Adobe would have spotted and corrected the bug during development.
Why use such misleading names for functions?
Posted Nov 25, 2010 10:18 UTC (Thu) by mpr22 (subscriber, #60784)
Any naive implementation of ISO C memcpy() is almost certain to have been unsafe in one direction. Either it starts at the end and works backward, making it work reliably for "dest > src, src + len > dest", or it starts at the beginning and works forward, making it work reliably for "dest < src, dest + len > src". (Of course, some bunch of demented jerks implementing a Deathmaster 9000 probably made it start at the middle and oscillate outwards.)
As for your proposed grand rename: You're quite right. Feel free to try and persuade the ISO C standard committee of your correctness.
Posted Nov 25, 2010 10:52 UTC (Thu) by xav (guest, #18536)
Just one Valgrind run found the problem. So the big lesson here is that Adobe doesn't even run Valgrind or equivalent (e.g. Purify) on their code. They wouldn't have corrected the bug during development, even if memcpy() had done a printf() to warn them.
No wonder their software is full of security holes.
Posted Nov 25, 2010 18:42 UTC (Thu) by RobSeace (subscriber, #4435)
We've already got one: memmove()...
(And, no, it's NOT really a "misleading" name... As I said in the old thread,
when the regions overlap, indeed the source region will no longer contain the
data it once did prior to the memmove(), since it's now been overwritten, at
least in part... So, the data truly was MOVED from source to destination, not
Posted Nov 25, 2010 18:45 UTC (Thu) by RobSeace (subscriber, #4435)
Posted Nov 25, 2010 21:36 UTC (Thu) by rvfh (subscriber, #31018)
You're correct, now that you say that, I understand why the name!
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds