Re: [SC-L] Why Shouldn't I use C++?
Ben Corneau wrote: From time to time on this list, the recommendation is made to never user C++ when given a choice (most recently by Crispin Cowan in the re-writing college books thread). This is a recommendation I do not understand. Now, I'm not an expert C++ programmer or Java or C# programmer and as you may have guessed based on the question, I'm not an expert on secure coding either. I'm also not disagreeing with the recommendation; I would just like a better understanding. I understand that C++ allows unsafe operations, like buffer overflows. However, if you are a halfway decent C++ programmer buffer overflows can easily be avoided, true? If you use the STL containers and follow basic good programming practices of C++ instead of using C-Arrays and pointer arithmetic then the unsafe C features are no longer an issue? C and C++ are very different. Using C++ like C is arguable unsafe, but when it's used as it was intended can't C++ too be considered for secure programming? No, it cannot. C++ is no more safe than C. C++ still supports many undefined operations, which is what makes a language unsafe. No way can C++ be considered a secure programming language. If you need a lean, small language for doing embedded or kernel stuff, then use C; you cannot afford the bloat of C++, so it is not appropriate. If you need a powerful, abstract language for building complex applications, then use C# or Java (or ML, or Haskell). They provide all of the abstraction and programming convenience of C++, and they also provide type safety. This means that there are no undefined operations, which is what makes them secure programming languages. There is no excuse for *choosing* C++, ever. Always avoid it. The only excuse for *using* C++ is that some doofus before you chose it and you have to live with the legacy code :) So why does C++ exist? Because technology has moved. 25 years ago, when C++ was invented, there was not a great supply of well developed type safe object oriented programming languages. So C++ seemed like an incremental improvement over C when it was introduced in the early 1980s. It did provide an improvement over C for developing large applications, where development costs due to complexity were the big problem, and bloat could be afforded. But that lunch has now been eaten by the type safe OOP languages of Java and C#. They are strictly better than C++ at complex applications, so there really is no excuse for using C++ to write new application code. And there never was an excuse for using C++ to write kernel or embedded code. You cannot afford the bloat of C++ there, and if your kernel is so complex that you need OOP to be able to program it, then your kernel design is broken anyway. I suppose there should be an IMHO in here somewhere in a rant like this. Feel free to insert it anywhere you like :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes ___ 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
Re: [SC-L] Why Shouldn't I use C++?
At 9:08 PM -0500 10/31/06, Ben Corneau wrote: C and C++ are very different. Using C++ like C is arguable unsafe, but when it's used as it was intended can't C++ too be considered for secure programming? What assurance does upper management have that C++ was used as it was intended rather than like C ? -- Larry Kilgallen ___ 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
Re: [SC-L] Why Shouldn't I use C++?
The biggest problem with C++ is that, like C, it is not type safe. The memory model is a disasterous sea of bits. Plus it is an arcane, hard to understand language prone to misunderstandings. If you can at all avoid C++, do so. Use Java, C#, or some other type safe alternative. gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: Ben Corneau [mailto:[EMAIL PROTECTED] Sent: Tue Oct 31 22:08:08 2006 To: SC-L@securecoding.org Subject:[SC-L] Why Shouldn't I use C++? From time to time on this list, the recommendation is made to never user C++ when given a choice (most recently by Crispin Cowan in the re-writing college books thread). This is a recommendation I do not understand. Now, I'm not an expert C++ programmer or Java or C# programmer and as you may have guessed based on the question, I'm not an expert on secure coding either. I'm also not disagreeing with the recommendation; I would just like a better understanding. I understand that C++ allows unsafe operations, like buffer overflows. However, if you are a halfway decent C++ programmer buffer overflows can easily be avoided, true? If you use the STL containers and follow basic good programming practices of C++ instead of using C-Arrays and pointer arithmetic then the unsafe C features are no longer an issue? C and C++ are very different. Using C++ like C is arguable unsafe, but when it's used as it was intended can't C++ too be considered for secure programming? Ben Corneau ___ 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 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. ___ 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
Re: [SC-L] Why Shouldn't I use C++?
| From time to time on this list, the recommendation is made to never | user C++ when given a choice (most recently by Crispin Cowan in the | re-writing college books thread). This is a recommendation I do not | understand. Now, I'm not an expert C++ programmer or Java or C# | programmer and as you may have guessed based on the question, I'm not | an expert on secure coding either. I'm also not disagreeing with the | recommendation; I would just like a better understanding. | | I understand that C++ allows unsafe operations, like buffer overflows. | However, if you are a halfway decent C++ programmer buffer overflows | can easily be avoided, true? If you use the STL containers and follow | basic good programming practices of C++ instead of using C-Arrays and | pointer arithmetic then the unsafe C features are no longer an issue? | | C and C++ are very different. Using C++ like C is arguable unsafe, but | when it's used as it was intended can't C++ too be considered for | secure programming? You could, in principle, produce a set of classes that defined a safe C++ environment. Basically, you'd get rid of all uses of actual pointers, and all actual arrays. Objects would be manipulated only through smart pointers which could only be modified in limited ways. In particular, there would be no way to do arithmetic on such pointers (or maybe the smart pointers would be fat, containing bounds information, so that arithmetic could be allowed but checked), arbitrarily cast them, etc. Arrays would be replaced by objects with [] operators that checked bounds. The STL would be an unlikely member of such a world: It models iterators on pointers, and they inherit many of the latter's lack of safety. (There are checked versions of the STL which might help provide the beginnings of a safe C++ environment.) You'd have to wrap existing API's to be able to access them safely. All the standard OS API's (Unix and Windows), everything in the C library, most other libraries you are going to find out there - these are heavily pointer-based. Strings are often passed as char*'s. Note that you can't even write down a non-pointer-based C++ string constant! But wait, there's more! For example, we've seen attacks based on integer overflow. C++ doesn't let you detect that. If you really want your integer arithmetic to be safe, you can't use any of the native integer types. You need to define wrapper types that do something safe in case of an overflow. (To be fair, even many safe languages, Java among them, don't detect integer overflow either.) By the time you were done, you would in effect have defined a whole new language and set of libraries to go with it. Programming in that language would require significant discipline: You would not be allowed to use most common C++ data types, library functions, idioms, and so on. You'd probably want to use some kind of a tool to check for conformance, since I doubt even well-intentioned human beings would be able to do so. It happens that C++ has extension facilities that are powerful enough to let you do most, perhaps all, of this, subject to programmer discipline. But is there really an advantage, when all is said and done? -- Jerry [Who uses C++ extensively, and does his best to make his abstractions safe] | Ben Corneau ___ 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
