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,75ce2ead897158b2
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.180.106.161 with SMTP id gv1mr2462113wib.4.1365104866184;
        Thu, 04 Apr 2013 12:47:46 -0700 (PDT)
Path: 
 p18ni37482wiv.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: My bug or else regarding Visibility Rules
Date: Thu, 04 Apr 2013 20:47:47 +0100
Organization: A noiseless patient Spider
Message-ID: <ly7gkigjrw.fsf@pushface.org>
References: <0c77e832-e12b-446d-af24-78d77c358f1e@googlegroups.com>
	<25ee066d-3270-4efd-829f-ed40b04c0655@googlegroups.com>
	<kj2en4$9q1$1@munin.nbi.dk>
	<89292c53-1d4e-48a7-b2ae-a10983ef4168@googlegroups.com>
	<kjdabm$dck$1@munin.nbi.dk>
	<d09afc35-2ca5-4b45-9734-7263e6d353c4@googlegroups.com>
	<lywqslgwyj.fsf@pushface.org>
	<e703d782-2e4c-4fe9-bcae-218abcc170f1@googlegroups.com>
	<lysj38hen1.fsf@pushface.org>
	<55c932fa-73a4-4999-a913-71d0d8ff4782@googlegroups.com>
	<lyfvz6hfmd.fsf@pushface.org>
	<282c7f39-f77e-416c-81f8-1f8fb5ad6d0a@googlegroups.com>
Mime-Version: 1.0
Injection-Info: mx05.eternal-september.org;
 posting-host="759faf2487b2ffad9ca6f5463a606de4";
	logging-data="24512"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX187xhdEj5nk3yrSVWYXpqB2IyXuAiN+aTc="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:lybnxYXX0K5r5KYU4wdMbGkQRV4=
	sha1:rydz9azSl/8MqM3wCA7rGObS0P0=
Content-Type: text/plain
Date: 2013-04-04T20:47:47+01:00
List-Id: <comp.lang.ada>

Anh Vo <anhvofrcaus@gmail.com> writes:

> On Thursday, April 4, 2013 1:19:54 AM UTC-7, Simon Wright wrote:
>> Anh Vo <anhvofrcaus@gmail.com> writes: > On Tuesday, April 2, 2013
>> 1:16:34 PM UTC-7, Simon Wright wrote:

>>> I do not understand this. Why isn't Buffer(1) valid if my index
>>> starts at 1?
>
>> Because after the index has wrapped round Buffer'Old(1) will not be the 
>> same as Buffer(1). 
>
> In this case the loop will drop out because loop lower end is greater
> than loop upper end.

Consider a queue of max length 5 containing letters. 5 letters (a, b, c,
d, e) have been Put, and one (a) Got.

   I
   a b c d e
     O

After the next letter is inserted, you'd have

     I
   f b c d e
     O

Your check is

   (for all I in 1 .. Queue_Length'Old =>
                 Buffer(I) = Buffer'Old (I))

which is going to fail.

>> No. You wrote 
>>   (Index mod Length) + 1 
>> but it should be 
>>   (Index + 1) mod Length 
>
> (In_Index + 1) mod length will raise Constraint_Error when the Queue
> is just full. In fact, (10 + 1) > 10 when the queue has the lenght of
> 10.

OK, I've never seen this way of managing an index but I can see it
working. Still think that 0-based is easier.

That said, (In_Index + 1) won't raise CE, because Index is a subtype and
inherits the operations of Integer. CE on assignment, sure, but the 'mod
Length' would have been applied by then.