> The bug, which has been documented in a CERT advisory, affects C code > in which, under some circumstances, buffer bounds checking can be > optimized out to produce binaries that are susceptible to buffer > overflows. [...]
> Of course, many/most SC-Lers will no doubt jump on this as another > example of why C is such a dangerous language to write (secure) code > in, and that's fine. Actually, it isn't. It's a dangerous language to write sloppy, buggy code in. Go read the advisory - it's only severely broken tests that are affected. Such code has always been broken; the recent change just changes the behaviour produced by such broken code, and I have trouble getting worked up about it. > But, I see the issue at least a little differently: a compiler making > decisions for the programmer and producing executable code that does > not accurately conform to what the programmer coded. It accurately conforms to what the programmer coded, just not to what the programmer intended to code. The "problem" affects only code that depends on certain pointer computations whose behaviour has never been promised by C. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
