Ada checks suppression thanks to compilation options and Ada conformity

Ada checks suppression thanks to compilation options and Ada conformity

[Christophe TRAVERS]

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.

Re: Ada checks suppression thanks to compilation options and Ada conformity

[Ludovic Brenta]

Christophe TRAVERS writes:
> From my point of view, these compilation options that can suppress
> the checks are a way to get around the Ada language norm.

You are correct.  See ARM 1.1.5(6) and 1.1.5(12).

-- 
Ludovic Brenta.

Re: Ada checks suppression thanks to compilation options and Ada conformity

[Jeffrey Creem]

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....

Re: Ada checks suppression thanks to compilation options and Ada conformity

[Adam Beneschan]

On Nov 8, 3:09 pm, Christophe TRAVERS <christophe.trave...@free.fr>
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?.

The compilation options are there for a reason---customers want them.
Generally, the idea is to leave checking on while you're testing a
program, and then when you're confident it works, you can compile the
program with checking off so that it runs faster.  Although you could
view this as "getting around the Ada language norm", there's nothing
wrong with it; the language designers wouldn't have added Suppress in
the first place if they intended for Ada to be a language for
"purists", rather than a language to be used in the real world.  I
doubt that there's any Ada compiler that doesn't have command-line
options to turn off checking.

If there's some sort of policy that forbids Suppress, but the code is
being compiled with options that achieve the same effect, it sounds
like there's a management problem.  Either the policy is too rigid to
be practical, or the programmers are too lazy to work within the
policy, or the programmers haven't been properly educated as to the
reason for the policy; or someone just doesn't know what they're
doing.

                                -- Adam

Re: Ada checks suppression thanks to compilation options and Ada conformity

[anon]

Even though your program may or may not be coded to raise a  
CONSTRAINT_ERROR or NUMERIC_ERROR, other functions and packages 
may use them or the hardware may raise them. 

Since the Suppress and Restrictions pragmas are apart of the Ada 
Standards, then they are not a way of getting around Ada norms. Ada 
unlike other languages has a few extra features built-in, which can be 
used for testing and debugging.  So during the development phase a 
programmer may use the normal build-in error checking and exceptions 
while testing a routine and then later add programmer defined validation 
when and as needed. Then once the routine is tested the build-in error 
checking can be removed to save execution time and space. 

Embedded devices such as cell phones or pdas are an example of where 
saving time and space is high on a programmer list. Because most Cell 
phones and PDAs have limited memory and both have slower clock speeds. 
So any time saving and space reducing method must be used in these 
devices.

Plus, in device driver routines the data should be validated before it 
is to and from the data buffer and program. But the transfer between the 
data buffer and the actual device the checking needs to be removed. Or 
these checks may cause either over or under runs for the transfer of data.

Also, once the data is validated at the entry or creation point it does 
not need to be validated at each routine that handles the data unless 
that routine alters the data.

Another example is accessing the co-processors like the FPU.  If the 
FPU does a divide, the only thing that happens is the correct FPU 
status flags are set and the normal FPU interrupt.  Now if the FPU 
does a divide-by-zero the only different is that the divide-by-zero 
status flag is set. It may or may not use the divide-by-zero CPU 
interrupt, but the CONSTRAINT_ERROR usage is software controlled.


--
-- a.adb
--
--
-- Uncomment either or both:
--
-- pragma Suppress ( All_Checks ) ;
-- pragma Restrictions ( No_Exceptions ) ;

with Ada.Text_IO ;

procedure a is

  b : string ( 1..1 ) ;

--  c : integer := 0 ;
--  d : integer := 1 ;
--  e : integer := 2 ;

  c : float := 0.0 ;
  d : float := 1.0 ;
  e : float := 2.0 ;

begin -- a
  Ada.text_io.put_line ( "Assign B" ) ;

  b := "55" ; -- Should cause a Constraint_Error 
              -- either pragma : allow code to continue

  Ada.text_io.put_line ( "Perform Divide by Zero" ) ;

  e := d / c ; -- Should cause a Constraint_Error 
               -- either pragma : allows code to continue for FPU
               --                 float instruction but a core dump 
               --                 may result for CPU integer divide

  Ada.text_io.put_line ( "End of Job" ) ;

end a ;


In <4733972C.C7E7BCE@free.fr>, Christophe TRAVERS <christophe.travers1@free.fr> writes:
>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.
>
>
>
>
>
>

Re: Ada checks suppression thanks to compilation options and Ada conformity

[Christophe TRAVERS]

You are write. The right sentence is "a part". A space is missing.

Dennis Lee Bieber a �crit :

> On Fri, 09 Nov 2007 06:07:41 GMT, anon@anon.org (anon) declaimed the
> following in comp.lang.ada:
>
> > Since the Suppress and Restrictions pragmas are apart of the Ada
> > Standards, then they are not a way of getting around Ada norms. Ada
>
>         Please...  "a part of" and "apart of" are totally opposite meanings.
> "... a part of ..." means "... a component of..." while "... apart of
> ..." means "... disconnected from ..., ... separated from ..., ... not a
> component of ...".
>
>         Yes, they do sound the same, when spoken -- so context is needed to
> figure out the proper meaning.
> --
>         Wulfraed        Dennis Lee Bieber               KD6MOG
>         wlfraed@ix.netcom.com           wulfraed@bestiaria.com
>                 HTTP://wlfraed.home.netcom.com/
>         (Bestiaria Support Staff:               web-asst@bestiaria.com)
>                 HTTP://www.bestiaria.com/

Re: Ada checks suppression thanks to compilation options and Ada conformity

[Christophe TRAVERS]

Many thanks for your answers,

The ada source code should have been developped in compliance with the Ada Norm
and a specific Ada satndard.

One of the rules of this Ada standard disables the pragma SUPPRESS.

The usage of this pragma SUPPRESS in dedicated parts of the source code could have
been acceptable on a case by case basis with the adequate justifications.

The fact is that the usage of these specific compiler options deletes all the
CHECKS inside the entire executable code without  justifications.

It is quite difficult to declare this Ada code conform the Ada norm and to the
specific Ada standards because on one hand pragma SUPPRESS is not used as required
but on the other hand CHECKS have been removed by another way (compiler options)!




Dennis Lee Bieber a �crit :

> On Fri, 09 Nov 2007 00:09:32 +0100, Christophe TRAVERS
> <christophe.travers1@free.fr> declaimed the following in comp.lang.ada:
>
> > 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?.
> >
>         Well... from my lowly perspective...
>
>         1) One text book describes "pragma" as a "directive to the
> compiler"... Compilation options can also be considered "directives to
> the compiler"
>
>         2) Many of my Ada texts tend to treat "pragma" as a "suggestion" for
> the compiler -- and indicate that compilers are allowed to ignore
> pragmas for which they are not coded
>
>         3) The absence of a "pragma X" does not imply "pragma NOT-X" (eg,
> absence of "pragma Suppress" does not imply "pragma Suppress NONE"
>
>         Conclusion:     Always read the documentation for the compiler in use.
>
> --
>         Wulfraed        Dennis Lee Bieber               KD6MOG
>         wlfraed@ix.netcom.com           wulfraed@bestiaria.com
>                 HTTP://wlfraed.home.netcom.com/
>         (Bestiaria Support Staff:               web-asst@bestiaria.com)
>                 HTTP://www.bestiaria.com/

Re: Ada checks suppression thanks to compilation options and Ada conformity

[Keith Thompson]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
[...]
> 	Well... from my lowly perspective...
>
> 	1) One text book describes "pragma" as a "directive to the
> compiler"... Compilation options can also be considered "directives to
> the compiler"

Sure, but pragmas are defined by the language; compilation options are
not.

> 	2) Many of my Ada texts tend to treat "pragma" as a "suggestion" for
> the compiler -- and indicate that compilers are allowed to ignore
> pragmas for which they are not coded

Implementations are allowed to define their own pragmas.  If a
compiler doesn't recognize the name of a pragma, it must issue a
warning, and the pragma has no effect.

But this doens't apply to pragma Suppress, which is defined by the
language; for that, you have to look at what the standard specifically
says about pragma Suppress.  A pragma Suppress gives the compiler
permission to omit the specified check(s).  It doesn't require it to
do so, and a conforming compiler could ignore pragma Suppress
altogether.

The purpose is not to allow operations that would raise exceptions;
it's to allow faster code to be generated, based on the assumption
that the exceptions would not have been raised.  In other words, using
pragma Suppress means that the burden of avoiding overflows and other
errors is on the programmer rather than on the compiler.

> 	3) The absence of a "pragma X" does not imply "pragma NOT-X" (eg,
> absence of "pragma Suppress" does not imply "pragma Suppress NONE"

Yes, it does.  The language standard requires certain checks to be
performed.  This requirement applies *unless* pragma Suppress is used.
If you don't use pragma Suppress (or some implementation-defined
pragma with similar semantics) and a required check is not performed,
then the implementation is failing to conform to the standard.

This isn't necessarily a bad thing.  If a compiler provides a
command-line option to suppress all checks, that can be quite useful;
it's easier than modifying the source every time you want to disable
or enable checks.  But a compiler with such an option specified is not
a standard-conforming Ada compiler.

There is a counter-argument to this.  The input to the compiler is one
or more compilation units; the standard doesn't specify how a
compilation unit is represented.  It could be argued that, if you
specify a compiler command-line option to suppress all checks, it
causes the compilation unit to consist of the specified source file
*plus* a "pragma Suppress(All_Checks);" at the top.

> 	Conclusion:	Always read the documentation for the compiler in use.

Absolutely.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"