On Thursday, November 18, 2010, 2:06:38 PM, Peter Jones wrote: > On 11/17/2010 10:59 PM, Matthew Garrett wrote: >> On Thu, Nov 18, 2010 at 12:42:56AM +0100, Kevin Kofler wrote: >> >>> Because it's NOT a bug in glibc, because what glibc does is CORRECT, >>> because >>> it actually POINTS OUT bugs in applications which are portability issues >>> and >>> can hurt future optimization opportunities (regardless of whether the >>> current implementation really is faster than before or not) and, most >>> importantly, because it is NOT our job to work around bugs in proprietary >>> software!
I'm in 100% agreement with Kevin's position on this matter. I also avoid Flash on Linux (and run with NoScript to keep a lot of other crap at bay). I have a couple of XP machines that I can use if I really need Flash. The glibc certainly conforms to the memcpy standard definition, and did not break the ABI. Apps that are not coded to use memmove when required are broken-by-design. QED. >> Pretty sure it doesn't point them out. It just breaks them. Could you >> shout a little less? I'm already hungover and I haven't even been to bed >> yet. This is a very low level and standard function, with absolutely no way to issue messages. On some CISC platforms (like zSeries mainframe), memcpy results in the compiler emitting a single instruction in the right conditions (move length is a constant). > Obviously we should make glibc check the ranges and abort() with a snarky > note. > Peter Not interested in that either. Those checks would significantly slow down all code. Not by a little, but by an enormous amount. Anything change at this point would be wasted effort - all to handle a few programs written by folks who _obviously_ never bothered to learn C programming correctly in the first place. C has come a long way since K&R, but this restriction has been in place since day-1. Fedora's limited resources are much better directed towards finding ways to make bad programs fail louder and earlier in the development cycle. Oh yeah... Adobe isn't part of Fedora, and doesn't concern themselves with our schedules. Based on their response, they don't really seem all that concerned with their own schedule regarding this issue. C'est la vie. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
