Fixing the glibc adobe flash incompatibility
Al Dunsmuir
al.dunsmuir at sympatico.ca
Thu Nov 18 19:39:37 UTC 2010
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
More information about the devel
mailing list