Secure Coding mailing list archives
Re: opinion, ACM Queue: Buffer Overrun Madness
From: "Gary McGraw" <gem () cigital com>
Date: Wed, 09 Jun 2004 15:57:14 +0100
Language makes a huge difference, eapecially in the realm of bugs. So not using C and C++ is smart. Use Java or C# instead. But poor programmers can, in fact, screw up in type safe languages as well. One major problem can be seen in the design flaw category of defects. Studies show that the split between bugs and flaws is 50/50. That means language choice is important but will not solve the problem. gem -----Original Message----- From: Kenneth R. van Wyk [mailto:[EMAIL PROTECTED] Sent: Wed Jun 09 09:06:48 2004 To: [EMAIL PROTECTED] Subject: Re: [SC-L] opinion, ACM Queue: Buffer Overrun Madness der Mouse wrote:
All that a "better" language will bring you in this regard is that it will (a) push the sloppiness into places the compiler can't check and (b) change the ways things break when confronted with input beyond the design underlying their code.
Although I am in favor of languages that help prevent such nasties as input buffer overruns, this is an excellent point. A sloppy programmer will write sloppy code. Reminds me of an old saying that I heard years ago while studying mechanical engineering: a determined programmer can write a FORTRAN program in ANY language. :-) (Well, notwithstanding FORTRAN's built-in ability of handling complex numbers, but I digress...) IMHO, the bottom line is that there's no excuse for sloppiness and a strong language can only do so much to prevent the programmer from his/her own sloppiness. Cheers, Ken van Wyk http://www.KRvW.com ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ----------------------------------------------------------------------------
Current thread:
- Re: opinion, ACM Queue: Buffer Overrun Madness, (continued)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 08)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Kenneth R. van Wyk (Jun 09)
- RE: opinion, ACM Queue: Buffer Overrun Madness Alun Jones (Jun 09)
- RE: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Blue Boar (Jun 10)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 08)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness David Eisner (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 09)
- RE: opinion, ACM Queue: Buffer Overrun Madness David Crocker (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Jared W. Robinson (Jun 10)
- RE: opinion, ACM Queue: Buffer Overrun Madness David Crocker (Jun 11)
- RE: opinion, ACM Queue: Buffer Overrun Madness ljknews (Jun 11)
- Re: opinion, ACM Queue: Buffer Overrun Madness der Mouse (Jun 11)
- RE: opinion, ACM Queue: Buffer Overrun Madness David Crocker (Jun 11)