> Note that this issue is in theory pretty serious as in principle _any_ > binary package in the archive could be affected.
Since the abs() is optimized away on miscompilations, searching for binaries that have the abs() symbol won't find the buggy ones. The only reliable way to find out what packages could be affected, is to grep for calls to abs() [I guess too many to hand-review]. Then the list could be filtered by dropping calls to abs() where parameteres are provably positive numbers (either constants, or unsigned types). Such a check could be implemented in static analysis tools, like CIL, but trying to compile the entire archive with CIL can be a challenge by itself. How do you intend to handle this bug for stable? Obviously updating all packages that call abs() is not a solution :( A quicker way to find out could be to compile all the archive with current gcc version. Then apply the patch that fixes the bug, recompile the entire archive, and see which .o,.so,.a, and executable files differ between the two. Is there a tool to automate such a task? --Edwin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]