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=0.1 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM,FREEMAIL_REPLY autolearn=no 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!feeder.eternal-september.org!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx14.iad.POSTED!not-for-mail From: Shark8 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:31.0) Gecko/20100101 Thunderbird/31.0a1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Heartbleed References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <%J32v.70539$kp1.45343@fx14.iad> X-Complaints-To: abuse@teranews.com NNTP-Posting-Date: Sat, 12 Apr 2014 04:58:35 UTC Organization: TeraNews.com Date: Fri, 11 Apr 2014 22:58:29 -0600 X-Received-Bytes: 5529 X-Received-Body-CRC: 2768078337 Xref: news.eternal-september.org comp.lang.ada:19254 Date: 2014-04-11T22:58:29-06:00 List-Id: On 11-Apr-14 13:33, Simon Clubley wrote: > 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. Well, there are several of us who are looking into ameliorate that condition w/ new open-source compilers. > 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. Oberon? > That compiler would be written in plain C making it easier to bring up > in a new environment with foreign compilers. I disagree; the compilers we build should *not* be dependent on C. -- There are too many easy-to-make errors, mistakes, and implementation-dependencies to really ensure that such a compiler is good. Indeed, I would argue that we need compilers built on formal-methods and verified to be correct. > 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. I wonder about that; is the runtime that difficult to port? What about having "staged" runtimes, with minimal, reduced, and nominal functionality? (Perhaps using the restriction pragmas...) Also, couldn't such a system be made so that the *really* system dependent stuff is all hidden in a package-body and [relatively] easy to port? eg Minimal : No tasking or protected objects, or unconstrained functions allowed. Reduced : No Tasking and Protected objects; but unconstrained functions are allowed. Normal : Everything. > 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. I don't know -- it might be time for professionals concerned w/ security to make a clean break and just use something else -- Eiffel is, from what I understand, ideal for library-writing with its heavy emphasis on interfaces [and design by contract]. > 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. Hm, good point. Ada has some *REALLY* good features when it comes to programming-in-the-large -- the YF-22 integration is astounding: 12 major avionics subsystems, across 650 Ada modules containing millions of lines of code, coded in 8 geographically distinct locations, took *three days!* Source: http://archive.adaic.com/docs/present/engle/comments/tsld033.htm > 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. Yeah -- that's rather disgusting. I blame the prevalence of c-style languages as well as universities 'targeting' them (that is to say ignoring non-C-style languages).