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!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: Bill White Newsgroups: comp.lang.ada Subject: Re: F-22 ADA Programming Date: Sun, 2 Nov 2014 15:40:46 +0000 (UTC) Organization: Aioe.org NNTP Server Message-ID: References: <220f97ab-9aa2-4961-b140-2b271c3ab99a@googlegroups.com> <99759c3f-a35f-4745-a8fd-2fb6ab6fb1aa@googlegroups.com> <48dc1630-8e7d-4e29-8bdd-53d74932d9d0@googlegroups.com> <88a7f98c-55c2-4b5f-8a9d-c8b7512781c8@googlegroups.com> <50cacb19-5d0b-4dbe-b91b-0b3b462913d6@googlegroups.com> <07d0ad94-160b-4873-ba1b-403e8c0bc420@googlegroups.com> <8100a013-e50d-4a19-b506-716288a2ccb4@googlegroups.com> NNTP-Posting-Host: Zfd+ckfpeF4ehQV7iij4yA.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:22978 Date: 2014-11-02T15:40:46+00:00 List-Id: On 2014-10-31, Maciej Sobczak wrote: > >> > That C++ bugs have more severe consequences than Ada bugs? :-) >> >> Are you kidding me? >> >> Are you not aware that buffer overflows are a major > > Yes, I am. And the recent Heartbleed mess is a very good example of why you are both right and wrong at the same time. > The problem is - most of the buffer overflows that we had to deal with > were related to foundation infrastructure, which has long historic > links. Nobody is going to replace those foundations without taking those > historic links into account - and choosing Ada at the top level does not > help much if foundations are not replaced. In the context of Heartbleed this > means that your Ada-based web service (like with AWS) would be compromised > anyway, because it would use the foundations that are broken, but which you > would not be willing to reimplement yourself. You are a master at living with and promoting failure as a lifestyle. Virtually everything you write screams "We can't, we can't!" Your "examples" have no connection to reality. They're just setups to prove why the world is coming to an end. The OpenBSD project got sick enough to throw out OpenSSL and replace it and with their new 5.6 release have shipped their own modifications. The work will be ongoing until all the problems in OpenSSL have been gutted and reworked. You can fix the world one step at a time. And if you don't start now then your failures are self-inflicted and you're part of the problem. Ada is not the answer, it's part of the answer. Being aware of how unsafe languages propose unacceptable risks is a discussion college kids don't even get into. That has to change. Engineering ethics have to be made part of an education. > Things look different in those deployments where you can control the whole >stack, like in embedded systems. There, "switching to Ada" is actually >meaningful and I fully applaud it. Which is actually very relevant and >viable with most safety critical systems. That's my world so I fail to see the necessity of gaining a few weeks schedule while giving up the ship with crappy third party libraries. We do everything ourselves and take responsibility for everything with no finger pointing. > >> C and C++ pointers are another area where wild storage references are >> common and have the same damaging effects as buffer overflows. Things like >> that just don't happen in Ada and other safe languages. > > They also don't happen with appropriate language subsetting, which is a >valid and widely used strategy in safety critical systems. There is no need >to abandon the whole language just because you want to get rid of one >language feature. But you do need to get rid of C and C++ because their culture is broken. They value ease of implementation over correctness. They value running on everything with a battery more important than doing whatever it is they're supposed to do well. That culture has to go. > OK, easy. There is a concept of widely accepted practice (also known as >"nobody was ever fired for buying IBM"). If all universities teach that >Java is the best technology and if all companies use it, then it must be an >accepted practice. Then, just as "nobody was ever fired for buying IBM", >nobody will be ever sued for writing business systems in Java. Java is not pretty but it's still a lot safer than C or C++.