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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bc7813b85b027ce5
X-Google-Attributes: gid103376,public
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: 11.6
Date: 1999/11/22
Message-ID: <wcchfiexwj3.fsf@world.std.com>#1/1
X-Deja-AN: 551699619
Sender: bobduff@world.std.com (Robert A Duff)
References: <3836ff5b_1@news1.prserv.net>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1999-11-22T00:00:00+00:00
List-Id: <comp.lang.ada>

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> Suppose we have a bounded stack:
> 
>   type Stack_Type (Size : Positive) is limited private;
> 
>   procedure Push
>     (Stack : in out Stack_Type;
>      Item  : in Item_Type);
> 
> private
> 
>   type Stack_Type (Size : Positive) is
>     limited record
>       Top : Natural := 0;
>       Items : Item_Array (1 .. Size);
>     end record;
> 
> end Stacks;
> 
> 
> Now consider an implementation of Push:
> 
>   procedure Push
>     (Stack : in out Stack_Type;
>      Item  : in     Item_Type) is
> 
>      subtype Top_Range is Positive range 1 .. Stack.Size;
> 
>      Top : Natural renames Stack.Top;
>   begin
>      Top := Top_Range'(Top + 1);    --???
>      Stack.Items (Top) := Item;
>   end Push;
> 
> 
> Is it possible, because of 11.6 permissions, that the explicit range
> check in the marked line can be optimized away?

Only in rather strange cases.  E.g., if you said:

    X: Stack_Type;
    ...
    Push(X, Some_Item);

and then never again referred to X, I believe 11.6 allows the compiler
to eliminate all the code, including the marked range check.

But why would you push some information onto a stack if it's provable
that you're never going to use that information?

Whether any given compiler is smart enough to do the above is another
question...

> Another question: if I compile this (or the instantiation?) with checks
> off, then will that cause the explicit range check to be omitted?

Yes, in practice.  A compiler should remove any suppressed check that
costs anything at run time, and on almost all machines I can think of, a
range check will cost something.  But that's just "Advice" -- formally
speaking, pragma Suppress doesn't *require* the compiler to do anything;
it merely *allows* the compiler to do something (namely, leave out
otherwise-necessary checks).

There are some machines on which overflow checking is free (or nearly
free), and a compiler might well ignore suppression of the overflow
check.  Similarly, it is possible to implement Storage_Error
(stack-overflow) checking for free using virtual-memory tricks -- I
would expect such a compiler to ignore the suppression of those checks,
since it would have to go to extra trouble for no benefit.

As to whether the pragma Suppress belongs on the generic or the
instantiation, I'm not sure if the RM really makes that clear (and I'm
too lazy to look it up), and I wouldn't be surprised if compilers differ
in that regard.  Certainly, a compiler that shares code for generic
bodies isn't going to pay attention to a pragma applied to the instance.
On the other hand, a macro-expansion implementation could conceivably
pay attention to either, or both.  I'm not sure what our compiler does.

In practise, a lot of people don't use pragma Suppress -- they use some
sort of compiler switch instead, and of course the semantics of that
switch are not addressed by the RM.  The compiler writer might define
the semantics of the switch in terms of an imaginary pragma Suppress.

- Bob