> 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.

Reply via email to