[M3commit] CVS Update: cm3

[Tony Hosking]

Clearly the source code is not legal.  It's just that your change breaks legal code:

VAR t: NULL;

which should emit a warning but nothing else.

The problem lies elsewhere...


On 3 Feb 2010, at 00:22, Jay K wrote:

> The backend should be able to cope with almost anything, I guess.
> But is the source code really legal?
> Shouldn't the front end error?
> The front end should error on some things, obviously.
>  
> Notice that all of the "internal errors" in this scenario are from
> the front end. Just the assertion failure is not.
>  
>  
> The front end doesn't handle its own stack correctly
> here, the errors come from its CG.m3 module that wraps
> the backend.
>  
> If this code is truly illegal and has no valid meaning, I think this is an ok change.
> The NT386 backend I guess should be hardened against front end bugs though.
>  
>  
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Tue, 2 Feb 2010 12:19:16 -0500
> To: jkrell at elego.de
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> That's the wrong approach.  A warning is not an error.  The backend should be able to cope with it...
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
> 
> 
> 
> 
> On 1 Feb 2010, at 20:17, Jay Krell wrote:
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/02/01 20:17:28
> 
> Modified files:
> cm3/m3-sys/m3front/src/values/: Variable.m3 
> 
> Log message:
> test case e0\e029:
> 
> MODULE Main;
> TYPE Rec = RECORD a: INTEGER END;
> VAR  r := Rec;    (* warning: variable has type NULL *)
> BEGIN
> INC(r.a)
> END Main.
> 
> followed by internal errors and an assertion failure in m3back
> 
> Change warning to error, and then it never gets to the internal errors.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100203/c974db76/attachment-0002.html>