[M3devel] ADR is *too* unsafe..

[Jay K]

The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
expected the compiler to have told me about it.
It is unfortunate. ADR should be *slightly* safer.
Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
It seems...quite unfortunate that the language is defined this way..

 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:01:09 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Why does the compiler break?
> Yes, VAR is *much* safer.
>
> On 2 Jun 2010, at 03:41, Jay K wrote:
>
>>
>> (*
>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>> to be at least as typesafe as C?
>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>
>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>> on some platforms on an assertion failure in C. And the
>> compiler isn't going to help me find these type mismatches? Ugh.
>>
>> This seems wrong. :(
>>
>> I guess I should really really use VAR then.
>> *)
>>
>>
>> UNSAFE MODULE Main;
>> IMPORT Ctypes, Cstddef;
>>
>>
>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>> BEGIN
>> F2(a); (* error, expected *)
>> END F1;
>>
>>
>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>> BEGIN
>> F1(a); (* error, expected *)
>> END F2;
>>
>>
>> VAR c:Ctypes.int;
>> d:Cstddef.size_t;
>>
>>
>> BEGIN
>> F1(ADR(c)); (* ok *)
>> F1(ADR(d)); (* error expected but no *)
>> F2(ADR(c)); (* error expected but no *)
>> F2(ADR(d)); (* ok *)
>> END Main.
>>
>>
>>
>> - Jay
>>
>