Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Glibc change exposing bugs
Posted Nov 10, 2010 22:24 UTC (Wed) by lmb (subscriber, #39048)
That behavior is undefined makes one only right as far as technicality is concerned; it does not imply that changing it silently is good software engineering practice, nor that it is right in terms of software providing a service to users.
Posted Nov 10, 2010 23:58 UTC (Wed) by nix (subscriber, #2304)
Posted Nov 11, 2010 2:29 UTC (Thu) by foom (subscriber, #14868)
Posted Nov 11, 2010 7:29 UTC (Thu) by nix (subscriber, #2304)
Posted Nov 11, 2010 17:30 UTC (Thu) by foom (subscriber, #14868)
Here we have a new bug in flash which appeared without a new version of the flash binary being uploaded. It's a substantively different situation.
Posted Nov 12, 2010 7:12 UTC (Fri) by hozelda (guest, #19341)
If you are that worried, you should work off stable versions or off a stable distributor that will manage this for you. You should not change key parts of the system if possible. glibc is a very key part. You should not update for optimizations, at least not without significant tests and only if you think it's worthwhile the gains. Stick to security updates or when a crucial problem has been solved.
Anyway, when an important "bug" like this comes up, projects should audit the code. In this case, the possible entry points to potential problems can be identified quickly for many projects (just search for memcpy).
The case of glibc involves well-defined standards. Most libraries do not have such carefully defined semantics, and we must rely on access to source code for the juicy bits.
OK, despite what I just said, if the gains here are not that useful, glibc should revert, at least for the time being. Reverting should not hurt those that adjusted already and will save those that have not. On the other hand, when will be the right time to change? Will people remember to fix this problem or will we just have a repeat later on? [Again, if the gains are negligible, the change in glibc should probably be avoided.]
Posted Nov 11, 2010 0:50 UTC (Thu) by MattPerry (guest, #46341)
But it is defined. The man page says not to use that function on overlapping regions. That applications ignored that and still functioned for so long is more a matter of good luck. That luck has run out due to their poor implementations and they should now be fixed.
Posted Nov 11, 2010 1:15 UTC (Thu) by Lovechild (guest, #3592)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds