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

AFAIKS GPC implements resticted types quite unlike what EP requires.

1. Restriced types should be different then underlying type (6.4.1 says

that restricted-type is a new-type, and new-type is different from other types. So according to rules for return values the following program (accepted by GPC in EP mode) is incorrect:

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

I agree.

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.

Emil

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.

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.

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.

Please note that it's a functional parameter. Without the word `function' you would be right.

In another mail you write:

BTW, please do not reply both to me directly and to the mailing list. The list should be used unless there is some reason to keep things private.

While I ask for the same as far as I'm concerned, your mails contain the header:

Reply-To: cbfalconer@worldnet.att.net

Which means (at least to me) that you do want a copy to your private address (which is what I'm doing now as well). If this isn't your intention, you might want to consider removing the `Reply-To' header or pointing it to the list ...

:-)

A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

Frank