Date: Fri, 14 May 1999 11:54:14 -0400 (EDT) From: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu> To: Alfred Perlstein <bright@rush.net>, Brett Glass <brett@lariat.org> Cc: Jamie Bowden <ragnar@sysabend.org>, chat@FreeBSD.ORG Subject: Re: BSD, GPL, the world today. (fwd) Message-ID: <crD4Qau00UwG0B8io0@andrew.cmu.edu> In-Reply-To: <4.2.0.37.19990513114425.04421810@localhost> References: <4.2.0.37.19990513095524.04429440@localhost> <4.2.0.37.19990513114425.04421810@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Excerpts from FreeBSD-Chat: 13-May-99 Re: BSD, GPL, the world tod.. by Brett Glass@lariat.org > Guess I'm attacking a "sacred cow." > > Sorry, but C and C++ are DEMONSTRABLY responsible for the lion's share > of the bugs in today's software. I'm sorry here, but I have to agree with Brett. What is wrong with saying C and C++ are tools that don't promote secure programming? C is certianly a language that promotes fast programs, that lets one get arbitrarily close to the hardware at hand while still retaining a good degree of portability, but certianly it does not allow for easilly prooved safe programs. We shouldn't have any personal baby languages when discussing them, and shouldn't feel bad when we use a langauge we know has faults, because this is the real world (at some point) and we have to use sub-optimal solutions so that SOMETHING gets done, so we learn a generally good langauge, get very good at it and use it. That should never change our view, though, that we are using the langauge out of practicality, and not because it is the best langauge that has ever graced our screens. I'd be the first to admit that while I know the deficiencies of C, I'd be most likely to write my next SUID binary in it, and go through the trouble of paying careful attention to buffer sizes, et al. Part of the reason is a compiler reason, no other copmiler gets as much attention and is as universal as gcc, and part is a learnign curve problem. If you look around, though, there exist langauges that have far less seams that can become security holes, languages where you can't access data as a collection of bits, can't access memory as one huge array.. the compiler forces you to work through the abstraction of the language. Now, this may feel limiting to some, but in reality you can do all the same data structures and techniques, only without all the efficiency tricks. But, when we're talking security, aren't limitations what you want? "Variable A can only be modified by so and so function which does careful checking of blah.." "This variable can only monotonically increase, and will raise an overlfow exception if it were to wrap around". C is not the end all langauge of computer science, although it will continue advid use through many many more years, but, maybe by realizing it's limitations, as well as techniques and models we may see elsewhere, we can not only give other langauges a look, but use those same techniques in our C code and improve it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?crD4Qau00UwG0B8io0>