Emil Jerabek wrote:

On Sun, Nov 30, 2003 at 06:46:06PM +0100, Waldek Hebisch wrote:

...

AFAIKS GPC implements resticted types quite unlike what EP requires.

2. According to 6.9.2.2 assignment to variable of restricted type is

legal, and IMHO the following program (rejected by GPC) is legal:

program prog; type a=0..5; b= restricted a; var c:b; begin c := 0; end .

My understanding of 6.9.2.2 is that either the value of the RHS should be assignment-compatible with the type of the LHS (which is not the case here), or with its underlying type, _provided the LHS is a function result variable_. Thus your example is IMHO illegal, whereas the program below is legal (and accepted by GPC):

program prog;

type a=0..5; b= restricted a;

function c:b; begin c := 0; end;

var d: b;

begin d := c end.

I agree, I misread 6.9.2.2 -- now the rules look much more consistent to me.

Later Emil Jerabek wrote:

The problem with functional parameters seems to be more general, there is nothing special with restricted types. For example, the following program is also incorrect, and accepted by GPC:

program prog; type a=0..5; var c:a; procedure foo(function bar:integer); begin end; function baz:a; begin baz := c end; begin foo(baz) end .

I agree that this program is incorrct. I think that the problem is more general. Typechecking in GPC still have many artifacts coming form the C compiler.

Frank Heckenbach wrote:

Before I start changing things, since I currently don't have the time to study the standard closely, could someone please describe the (expected) effects of `restricted' in plain words (assignments, var/value parameters, function results, record fields, across import/export if there's anything special etc.).

AFAIKS the basic rule is that there should be no way to tamper/leak info from restricted variables/values (without having the underlying type in hand). The detailed rules either implement this or are added for consistency. The first barrier is that restricted types form its own class of types, so most operations on restricted variables/values are prohibited by type rules.

...

By the way, greping the testsuite for `restricted' gave me no matches...

Maybe a typo? There are some test programs (e.g. fjf594*.pas), but probably not enough (or maybe not even all correct). If someone can correct/complete them, I'd also appreciate it.

Yes, I probably made a typo. Now I can find test programs. After the message from Emil I think that `fjf594a.pas' is incorrect: assignment of restricted values is allowed only to return value of a function, not to normal variables.

I think that `New' in `fjf594k.pas' is incorrect -- `i' is not a pointer and AFAIKS `New' can be applied only to pointers.

Some more examples:

Any structured type which has restricted component becomes unassignable. But GPC allows this:

program restr1; type a = 0..5; b = restricted a; c = record i : b end;

var d ,e : c; begin d := e end .

Restricted components are forbiden in variant part of a record:

program restr2; type a = 0..1; b = restricted a; c = record case a of 0: (ri : b); 1: (ui : a) end;

var d ,e : c; begin d := e end .

GPC leaks restricted values trough `Ord' function:

program restr3; type a = (foo, bar); b = restricted a;

var d : b; c : integer; begin c := ord(d) end .

Restricted components are forbiden in files:

program restr1; type a = (foo, bar); b = restricted a; c = file of b; begin end .

I have more examples, but IMHO it is enough for this message.

Emil Jerabek wrote:

The problem with functional parameters seems to be more general, there is nothing special with restricted types. For example, the following program is also incorrect, and accepted by GPC:

program prog; type a=0..5; var c:a; procedure foo(function bar:integer); begin end; function baz:a; begin baz := c end; begin foo(baz) end .

Here the problem was simply that results of functional parameters weren't checked strictly enough, which is easy to fix. (Attached -- unfortunately, not all fixes are so self-explaining. ;-)

(But there are indeed more problems with restricted types. I'll come back to them later.)

Frank

CBFalconer wrote:

Frank Heckenbach wrote:

...

Emil Jerabek wrote:

...

The problem with functional parameters seems to be more general, there is nothing special with restricted types. For example, the following program is also incorrect, and accepted by GPC:

program prog; type a=0..5; var c:a; procedure foo(function bar:integer); begin end; function baz:a; begin baz := c end; begin foo(baz) end .

Here the problem was simply that results of functional parameters weren't checked strictly enough, which is easy to fix. (Attached -- unfortunately, not all fixes are so self-explaining. ;-)

How is it incorrect? a being a subrange of integer, baz seems to satisfy the requirements for a parameter of foo. At least as I see it.

From ISO 7185, 6.6.3.5 Functional parameters:

"The result-type closest-contained by the formal-parameter-section shall denote the same type as the result type of the function."

An integer subrange type is not the same type as the integer type; therefore, baz fails the same type result type requirement.

In order for the example to legal, the requirement would have to have been compatible types for result types but that isn't what ISO 7185 (or ISO 10206) actually requires.

Gale Paeper gpaeper@empirenet.com