Paul Rubin wrote: > Jeff Schwab <[EMAIL PROTECTED]> writes: >>> there's actually a published book specifically about C++ pitfalls. >> Mercy, a whole book? > > http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?EAN=9780201179286 > >>> C and C++ should practically be outlawed at this point. >> On what grounds? "I don't approve of the programming language you're >> using. Cease and desist. Nyah!" > > Well, "outlawed" of course is a figure of speech; however use of those > languages should be a red flag in a design review, and a factor in > determining product liability if a program misbehaves.
Your product gets the benefit of the doubt if it was written in Python, but not if written in C? What if the Python interpreter screws up? > Think of all > the buffer overflow exploits against Microsoft Windows programs that > couldn't have happened if Microsoft had used safer languages. There > was clearly a failure to use best engineering practices. In the first place, you're not distinguishing C from C++. I know you think they're the same. They're not. Python's array bounds checking is done in C, as is the case for traditional OS kernels. C++, like Python, offers you container types that "smell" like arrays, but do safety checking under the hood; the C++ bounds checks, unlike the Python checks, are done in-language. If C++ were marketed like Java, people might advertise that the C++ standard containers are "pure C++," or that "C++ is written in C++". Secondly, you're going to have a hard time writing an operating system kernel without fixed-size buffers. You have to read data in chunks of some size. It's fine to say that buffer access should be checked to make sure indexes should be in range, but somebody actually has to write the code to do the checking, and then programmers have to use it. Buffer overflows are the result of developers deliberately choosing not to use bounds-checking. In Python, somebody could still define a monolithic array, use different parts of it to represent different things, and then "oops" lose track of their index, thereby overwriting one part of the array with data that should have stayed in the other part. If you're thinking "Yeah, they *could*, but only a dodo would do that, and it's not Python's fault that the programmer did something bone-headed," then you're beginning to get the picture. If you somehow wrote an OS kernel in Python, and the above-mentioned bone-headedness took place, then there would be no "lower level" to save your OS from having a dangerous security hole. Even if the hardware supported checked access for large quantities of arbitrarily sized arrays, somebody would have to enable that access. Even then you're trusting the hardware developers to check for invalid indexes (bus errors and seg faults). Should we outlaw computer hardware, too? Thirdly, you mentioned a "failure to use best engineering practices." If you mean there was a failure to design and implement a bug-free operating system, then by Jiminy, you're right. "Best practices," though, is usually just what managers say when they mean "what everybody else is doing." The idea is that if you're a manager who sticks to "best practices," then if everything goes to hell, the problem can't be linked specifically to you. Server-side Python is now, at this very moment, becoming acceptable as "best practice." It's no better or worse for this; it's just that a lot more uninspired, uncreative programmers are about to start using it. Do not underestimate their ability to make any programming language look bad. If you make it fool-proof, they'll build a better fool. The only way to keep them from writing code that will blow up at run-time is to impose formal verification of their program, every time they change it; that's what the C++ static type system lets you do, in a limited and easily subverted way. Even if you could somehow remove every feature open to potential abuse, and thereby dodo-proof the language, the result would be a slow, weak, ugly language that non-dodos would not want to use. But hey, at least it would still be "best practice." -- http://mail.python.org/mailman/listinfo/python-list
