| |||||||||||||
On breaking thingsOn breaking thingsPosted Nov 25, 2010 7:33 UTC (Thu) by error27 (subscriber, #8346)In reply to: On breaking things by nybble41 Parent article: On breaking things "The glibc change only broke programs which used the API contrary to its explicit interface requirement--every C programmer should know that you never use memcpy()" The memcpy() change exposed a similar bug in glibc. So the Flash people maybe aren't idiots after when compared to the glibc people.
(Log in to post comments)
Why use such misleading names for functions? Posted Nov 25, 2010 9:40 UTC (Thu) by rvfh (subscriber, #31018) [Link]
I think having memcpy() and memmove() is a mistake.
* memcpy() should do the right thing, which is copy memory, safely. * memmove() should not even exist, especially not which such a misleading name.
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) [Link] 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.
Why use such misleading names for functions? Posted Nov 25, 2010 10:52 UTC (Thu) by xav (guest, #18536) [Link]
> 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.
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.
Why use such misleading names for functions? Posted Nov 25, 2010 18:42 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
> memcpy_nooverlap() (feel free to find a better name)
We've already got one: memmove()...
(And, no, it's NOT really a "misleading" name... As I said in the old thread,
Why use such misleading names for functions? Posted Nov 25, 2010 18:45 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
D'oh! Of course, I misread, and of course memmove() is the name for memcpy_overlap(),
and your hypothetical memcpy_nooverlap() is just memcpy()... But, it has literally ALWAYS been this way, and any C programmer worth half a damn knows this is how memcpy() and memmove() works... It's widely documented in various standards, and misusing memcpy() in place of memmove() will cause you lots of trouble on various other libcs... Just because glibc has been forgiving of the blatent misuse prior to now is no reason to continue to tolerate it...
Why use such misleading names for functions? Posted Nov 25, 2010 21:36 UTC (Thu) by rvfh (subscriber, #31018) [Link]
> And, no, it's NOT really a "misleading" name...
> (...) > the data truly was MOVED from source to destination (...)
You're correct, now that you say that, I understand why the name!
|
|||||||||||||