| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 10, 2010 20:01 UTC (Wed) by mrshiny (subscriber, #4266)In reply to: Glibc change exposing bugs by jwb Parent article: Glibc change exposing bugs
Please.
First of all, glibc supports proprietary software, which is why they allow proprietary software to link to it. So punishing certain programs for license choice by making subtle (and sometimes unjustifiable) changes to API seems like a highly passive-aggressive approach to their ideology.
Second of all, there MUST be a way to preserve backwards compatibility AND allow for future progress. Remember: all of your open-source programs which exhibit this bug are just as broken as Flash, except that if someone tracks it down in the Free software it can be fixed for future versions. But that doesn't help anyone who already has the software installed. I just can't imagine that the glibc people couldn't come up with ANY approach that works for everyone. Off the top of my head I can think of several; probably there are reasons why they are problematic, but in that bugzilla entry even Linus Torvalds was unable to prove that the glibc approach was warranted at all, let alone warranted for everyone all the time.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 10, 2010 22:49 UTC (Wed) by cesarb (subscriber, #6266) [Link]
> So punishing certain programs for license choice by making subtle (and sometimes unjustifiable) changes to API seems like a highly passive-aggressive approach to their ideology.
This was not an API change. The memcpy() API has always been that the regions cannot overlap, and has been so for decades. This was just a change in the implementation details.
Glibc change exposing bugs Posted Nov 11, 2010 0:33 UTC (Thu) by marcH (subscriber, #57642) [Link]
> This was not an API change.
Agreed, let's not confuse API change with "change of undefined behaviour". It may look the same but it is different.
That's what symbol versioning is all about. Posted Nov 10, 2010 23:03 UTC (Wed) by khim (subscriber, #9252) [Link] GLibC does have such mechanism: it's called ELF symbol versioning. But the policy does not cover cases similar to discussed one: if it's bug in a program (and the fact that regions must not intersect is well-documented one... heck, it's reason for memmove(3) existence), then there will be no new version of function. The question of "do we actually want such change" is separate issue.
|
|||||||||||||