<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Disclosure: I knew they are of type "NULL", but I didn't/don't know what that type is, or have a mental model for it.<BR>This about the only place in the entire tree that uses this type. It triggers an error in the C backend, but should be trivial to fix. I can just treat this as "ADDRESS" presumably. Checks that it is NIL, that is the frontend's job. The error is just that I check that I know about every type. Some types are "predeclared", some come from the frontend. I'll predeclare this. Arguably nothing should be predeclared.<BR> <BR> <BR> - Jay<br> <BR><div><div id="SkyDrivePlaceholder"></div>> Date: Sun, 21 Apr 2013 21:03:02 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] null type?<br>> <br>> <br>> <br>> On 04/21/2013 03:55 PM, Jay K wrote:<br>> > What is the meaning of this:<br>> ><br>> > cm3/elego/graphicutils/src/RsrcFilter<br>> ><br>> > init(p1, p2, p3, p4, p5, p6 := NIL) : T;<br>> > (* Initializes the resource search path. *)<br>> ><br>> ><br>> > PROCEDURE Init(self : T; p1, p2, p3, p4, p5, p6 := NIL) : T =<br>> ><br>> <br>> Modula-3 says:<br>> <br>> 2.2.7: 'The following reference types are predeclared:<br>> ...<br>> NULL Contains only NIL'<br>> <br>> And:<br>> <br>> 2.2.8: 'A formal parameter declaration has the form<br>> Mode Name: Type := Default<br>> ...<br>> If Type is omitted, it is taken to be the type of Default.'<br>> <br>> And:<br>> <br>> 2.6.6: 'The literal "NIL" denotes the value NIL. Its type is NULL.'<br>> <br>> So all the pi's have type NULL, and only NIL can be passed to them<br>> as actuals. That's what the language says. It looks like the code<br>> in Init thinks it can get non-NIL reference values, but an attempt to pass<br>> one in a call should fail a runtime assignability check, since it<br>> won't be a member of NULL.<br>> <br>> When Init passes one of these to Convert (Yes, I peeked into<br>> RsrcFilter.m3), it is assignable, with no runtime check. Convert<br>> thinks it has a REFANY, and other calls to Convert could indeed<br>> give it something non-NIL, but not from the calls in Init.<br>> <br>> Of course, unsafe code could probably LOOPHOLE (remember, any word<br>> can be verbed) something non-NIL to NULL and pass it to init/Init.<br>> If the compiler did the most obvious thing, this might do what was<br>> apparently intended.<br>> <br>> But then again, a compiler would be fully compliant with the language<br>> and perfectly within its rights to optimize out such a parameter,<br>> not actually pass it at runtime at all, and just insert constant NIL<br>> wherever the formal was referenced in the body of Init, thus undermining<br>> the above intent.<br>> <br>> Which makes for a good example of how unsafe code (almost?) always<br>> depends on assumptions about what a compiler will do.<br>> <br>> ><br>> > What are the types of p1, p2, etc.?<br>> ><br>> ><br>> > - Jay<br>> <br></div> </div></body>
</html>