| |||||||||||||
The real problem hereThe real problem herePosted Nov 10, 2010 23:38 UTC (Wed) by bojan (subscriber, #14302)Parent article: Glibc change exposing bugs
Is, of course, the fact that flash is not open source, so the bug cannot be easily fixed. If flash was an open source package in Fedora, the function use would be changed to memmove(), package would be rebuilt and issued as an update. And nobody would be talking about preserving the old memcpy() behaviour at all.
(Log in to post comments)
The real problem here Posted Nov 11, 2010 12:58 UTC (Thu) by nye (guest, #51576) [Link]
>And nobody would be talking about preserving the old memcpy() behaviour at all.
Which would of course be a great shame, because avoidably breaking existing applications is wrong, regardless of whether that program has a hidden bug in it or not.
The real problem here Posted Nov 11, 2010 18:41 UTC (Thu) by xilun (subscriber, #50638) [Link]
So why don't you just freeze all the programs you use forever and never upgrade them again on your computers? That would give you this magical property...
Two schools Posted Nov 12, 2010 13:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Your belief is sometimes called the "Raymond Chen" school of software engineering, although mostly because he's documented it rather than because he's in some way responsible for the Windows team taking this approach.
You can get yourself tied in some terrible knots this way. Chen's blog The Old New Thing is currently documenting how starting from [let's not annoy CP/M programmers] got them to [making an OS component optional causes security vulnerabilities in third party programs], over the course of a decade or so. Every step along the way is completely rational but the result is a confusing, insecure mess that's hard to reform.
But the alternative school, where everything not tied down and documented is up for grabs, and the tied down stuff might be cut loose and "deprecated" with relatively little notice, causes its fair share of problem as we've seen with the thread's topic.
Let me say this: It is very far from clear which of the alternatives here is better for anyone, from users to developers to OS vendors, let alone which would be best for all.
Two schools Posted Nov 12, 2010 17:48 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] I can just imagine trying to convince the glibc folks to autodetect SimCity to dynamically change how free() works.
The real problem here Posted Nov 19, 2010 2:14 UTC (Fri) by linuxrocks123 (guest, #34648) [Link]
Well, actually, in this particular case you could probably rewrite the binary to call memmove instead of memcpy fairly easily if you really wanted to.
---linuxrocks123
|
|||||||||||||