Re: Abbreviation of arrays, scope.

[Michael Poole <mdp2@xxxxxxxxxxxxxxxxxxxxxxxx>]

In message <Pine.SOL.4.10a.9912212139190.3250-100000@xxxxxxxxxxxxxxxxxxx
k>, Lee Benfield <lab27@xxxxxxxxxxxxxxxx> writes
>Hi -
>
>(This question relates to Kroc1.0.3B on Linux GLIBC 2.1)
>
>Has the occam(2.1) spec changed since the snippet below?  
>The code below shouldn't compile, as the array z should not
>be able to be referenced. 
>
>Cheers,
>
>Lee.
>
>------
>
>Occam 2.1 Manual, SGS Thompson
>[72 occ 45 03] P. 42
>
>"Where an abbreviation is of a component of an array, no other
>reference may be made to any other part of that array, except
>in a further abbreviation...."
>
>------
>
>PROC badAbb([]INT z)
>  INT x IS z[2]:
>  SEQ
>    x := 3
>    z[4] := 3:
>
>PROC test (CHAN OF BYTE key, screen, error)
>  [32]INT z:
>  SEQ
>    badAbb(z)
>:
>
>

I have given this fragment to the TDS3 occam compiler and it finds
the aliasing error Lee mentions. I have also given it to o21k which is
the compiler in the Linux Kroc, and the error is not detected.
The D7205 occam compiler also fails to find the error, so I presume
that either the compiler knows that this instance is benign, or it
is not doing all the checking it ought. An error IS found if z[i]
is used instead of z[4], where i is an INT which has previously been
assigned the value 4.

The same behaviour is observed with the fragment in the occam 2 manual
(p58) which I copied unchanged when I wrote p42 of the occam 2.1 manual.
I was never aware of any intention to change the definition of the
language in this area at any stage, but maybe Conor will be able to
help on this.

If anyone thinks this is important I will check further in the next
Millennium.
-- 
Michael Poole
15 Heather Close, STROUD, GL5 3QY
01453 759557