From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Heartbleed Date: Fri, 11 Apr 2014 19:33:57 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> Injection-Date: Fri, 11 Apr 2014 19:33:57 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="10056"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/UQSxC/iIY0T7KmJ3N4u75iGAmfm4GO1g=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:zfch1nHMWdfO3Oq8G9B5R/XYsJg= Xref: news.eternal-september.org comp.lang.ada:19248 Date: 2014-04-11T19:33:57+00:00 List-Id: On 2014-04-11, kalvin.news@gmail.com wrote: > As a (embedded) C programmer, I have seen over and over again similar > problems appearing in the code I maintain. Also, I do make similar mistakes > ie. miss the bounds checking in the functions as I (wrongly) assume that > the bounds have been checked in upper levels which will eventually use my > functions. Not to mention crappy pointer trickery. I do blame C in many > respects, that it allows unsafe constructs and allows sloppy coding > practices. I am also surprised (actually dissapointed) that C is used so > widely. In my opinion, as a C programmer, C should not be allowed to be > used at all. C is broken, C is bad. C++ is also broken and C++ is bad. I > would like to see that programmers would adopt to something more secure > programming language, which would make creating buggy and sloppy software a > bit harder. Whether it is Ada or something else. > I strongly agree with this. C, even in 2014, is used for critical libraries so there's clearly a place for a simpler language with comparable functionality to C, but with the functionality done in a type safe way. Sadly, I agree with a previous post that it's unlikely to be Ada because of the vast range of systems these libraries run on and because of the major issues around getting Ada (which in this context really means GNAT) to run in a new environment. What may be a viable option would be if a simpler Wirth style language existed and whose compiler generated object code compatible with gcc and used binutils for it's assembling/linking phase. That compiler would be written in plain C making it easier to bring up in a new environment with foreign compilers. For the libraries C is being used for and for which the security issues exist, you don't need a huge Ada style runtime with a huge Ada style language functionality that's damned difficult to port to a new environment. However, to stand a chance of displacing C you need a compiler which runs in the same range of environments as C does and you need libraries written using this language to be _easily_ callable from C and the other languages which currently use C libraries. That's the reality anyone wanting to replace C is facing. BTW, once you have people exposed to type safe programming, then maybe you can introduce them to Ada for the large projects. One of the major revelations for me over Heartbleed was seeing people discuss the need for a safer language and immediately jump to languages like Java. The idea that there might be a option in between, a traditional compiled language which offered type safe functionality simply didn't seem to occur to them. It's as if C, C++ and Java are the only languages most people seem to have heard about. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world