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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.99.113.75 with SMTP id b11mr39285694pgn.162.1481274735642; Fri, 09 Dec 2016 01:12:15 -0800 (PST) X-Received: by 10.157.37.247 with SMTP id q110mr5307757ota.5.1481274735572; Fri, 09 Dec 2016 01:12:15 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!p16no4564717qta.1!news-out.google.com!j8ni19649qtc.0!nntp.google.com!n6no4568183qtd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 9 Dec 2016 01:12:15 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:5985:2c17:9409:aa9c; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:5985:2c17:9409:aa9c References: <92ed75e9-baae-455c-9e34-53348dc6eaef@googlegroups.com> <03847fd7-5699-48de-bb3c-ef5512398f26@googlegroups.com> <3ef819e8-55f7-4ef7-9f37-77e6abc33f98@googlegroups.com> <47366b42-c0a3-41bf-a44a-5241c109d60f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Robert Eachus Injection-Date: Fri, 09 Dec 2016 09:12:15 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4864 X-Received-Body-CRC: 3490570489 Xref: news.eternal-september.org comp.lang.ada:32694 Date: 2016-12-09T01:12:15-08:00 List-Id: On Monday, December 5, 2016 at 6:09:42 AM UTC-5, Simon Wright wrote: > >>> I would consider it a major bug to have a pragma Assert that could > >>> fail at run-time absent a hardware failure or some such. (Even though > >>> it would be turned off in production code.) >=20 > Yes. Though it's really up to the system engineers to decide on system > behavior in the presence of software failure. I picked this since it quotes me, rather than to pick on Simon. The import= ant thing that is getting missed in this discussion is that there are lots = of uses for software. I spent most of my career working on software for ra= dars, planes, and missiles, where production software means the stuff that = flies--or gets installed on a mountain with no software or system engineer = in easy reach. Sometimes that means that crashing the software (well a controlled crash th= at turns off the radar then restarts from the beginning) is the right safet= y feature. But in an aircraft you leave it to the pilot to shut the engine= s down. Yes, the engine might be about to tear itself into little pieces i= n five minutes--but this may be the only working engine that will get you t= o the airport. I remember one incident where the mechanic didn't put the o= -rings on the (new) oil plugs. The pilot shut down the center engine for l= ow oil pressure, and headed back to Palm Beach. Then the other two engines= had oil pressure warnings. He ran them as long as possible, glided until = just above the waves--and restarted the center engine. Safe landing, barel= y. But notice that the cockpit crew should never end up fighting the software = warning system. If it doesn't help, cut the warning. Read about what happ= ened to the Quantas A380, when an engine failed and cut some of the wires i= n the wing. Telling the cockpit crew IN THE AIR that thus and so is not re= porting every few seconds is NOT helpful. On the ground? Fine, if it is a = deadline issue. (Hmm. Not clock deadlines, deadlines as in the plane won't= fly.) Why do I remember such incidents? And why did I consider it important for = me to know about them. It all comes back to this issue. Who are your diag= nostics and exceptions expected to help? To bring it back here, as far as I am concerned, the Assert feature makes i= t easier to insure that debug only code does not end up causing real accide= nts. Exceptions often need to be handled in production code, but such exce= ptions should usually be wrapped closely in specific handlers. Oh, and that handler around one line might as well say "when others." Ther= e may be some code you don't see that could result in an unexpected excepti= on, say "Device_Error" not "Use_Error" when reading from a file, but the be= havior to deal with it is the same.