Secure Coding mailing list archives
RE: opinion, ACM Queue: Buffer Overrun Madness
From: "David Crocker" <dcrocker () eschertech com>
Date: Fri, 11 Jun 2004 18:52:58 +0100
ljknews wrote:
And there are ways of using Assembly Language to avoid pitfalls that it provides. There are ways of using horse-drawn carriages to avoid the major reason (think street cleaning) why the automobile was embraced in urban areas during the early part of the 20th century. What there are _not_ are reasons for new development to cling to languages which make flawed constructs easy for the individual programmer to misuse. << There is often one very good reason for clinging to such languages: because there is no other suitable language available. As has already been pointed out, there is usually very little alternative to C/C++ when it comes to kernel mode code. I would love to see a safer alternative to C/C++ for writing operating system kernels, device drivers and real-time embedded applications (yes, I know Ada can be used for the latter, buts its package structure and associated "with-ing" problem can be a real pain in large systems). The newer programming languages such as Java, C# and Eiffel are all designed for applications and make heavy use of garbage collection (which is a boon to application writers, but a no-no for kernel code and many embedded apps). What I don't understand is why the language standardisation committees don't remove some of the unsafe dross when they bring out new language revisions. A classic example is the failure to define the type of a string literal in C as "const char*". Just imagine if we had a new version of C++ with all the unsafe stuff removed. Backwards compatibility would not be a problem in practice, because the compiler suppliers would provide switches to make their new compilers accept obsolete constructs. As for non-real-time application-level code, I gave up writing them in C++ by hand long ago. [Actually I prefer to write specifications, verify them, and let a code generator produce correct C++ from them; but that is another story.] David Crocker Consultancy & contracting for dependable software development www.eschertech.com
Current thread:
- Re: opinion, ACM Queue: Buffer Overrun Madness, (continued)
- 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 Peter Amey (Jun 09)
- Re: opinion, ACM Queue: Buffer Overrun Madness Gary McGraw (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)
- Re: opinion, ACM Queue: Buffer Overrun Madness Crispin Cowan (Jun 11)