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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1f0967a619e5d83e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!out03b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny04.POSTED!c9e1c1fe!not-for-mail From: Jeffrey Creem User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada checks suppression thanks to compilation options and Ada conformity References: <4733972C.C7E7BCE@free.fr> In-Reply-To: <4733972C.C7E7BCE@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 09 Nov 2007 00:15:01 GMT NNTP-Posting-Host: 71.168.122.204 X-Complaints-To: abuse@verizon.net X-Trace: trndny04 1194567301 71.168.122.204 (Thu, 08 Nov 2007 19:15:01 EST) NNTP-Posting-Date: Thu, 08 Nov 2007 19:15:01 EST Xref: g2news1.google.com comp.lang.ada:18224 Date: 2007-11-09T00:15:01+00:00 List-Id: Christophe TRAVERS wrote: > I send this message in order to get your opinion on the following > subject : > > An Ada program was supposed to take into account the Ada exceptions : > CONSTRAINT_ERROR, NUMERIC_ERROR, ... > The pragma SUPPRESS was forbidden. So, it was not used in the Ada source > code. > Everybody was convinced that the exception mechanism was fully > operational in the embedded object executable. > > Nevertheless, the object code was compiled thanks to the Ada TARTAN > compiler with some compilation options have suppressed all the "checks" > in the entire object code. > > From my point of view, these compilation options that can suppress the > checks are a way to get around the Ada language norm. > > What it you opinion on this suject?. > > Sincerely. > If I understand what you are implying I think it is fair to say that the purpose of the options is not to get around the Ada language norm. Specifically, if you mean that you think the most likely reason someone did this was to remove the checks so they could write bad code without the compiler bothering them then I suspect (hope) you are wrong. It is non uncommon in an embedded system with limited processing resources to run with checks suppressed to allow the code to fit either the actual processor or some 100% processing reserve requirement. All of Ada's static checking rules will still apply so much of what you might think someone was trying to get away with will still be caught. It is certainly possible that it was done for the reason that I think you are implying, but it is not likely. It is also possible that even a well intentioned team that ran with checks suppressed for all the right reasons has allowed a small number of bug (detections) to creep in that would be triggered if checks are enabled. It is a good practice to run 'some' with checks enabled even if project needs require that the final build have checks suppressed. Having said that, since one should 'test the way you fly' I would also say that I would expect a majority (if not all) of the qualification level testing to be done with the deployed switch conditions. I wonder what you really mean by "Everybody was convinced that the exception mechanism was fully operational in the embedded object executable". Are you implying that after reading the compiler documentation and understanding all of the flags you had every reason to believe checks were enabled because the documentation was wrong/misleading and or because there is a compiler bug? Or, do you mean that everyone just assumed it would be so? Certainly the fact that pragma suppress was forbidden implies some form of the latter....