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