[M3devel] language question -- locals uninitialized or zero?

[Daniel Alejandro Benavides D.]

Hi all:
semantically the error is are in the program, not in the operating system (untrapped vs trapped error), all untrapped errors must be stopped before making any modification of the runtime system (not in the operating system abstraction).
You can run in a untrapped error, but ignore it silently with automatic initialization like you are trying,  doesn't help, your program is ill behaved and must be rejected in a checked runtime error. If you run it and don't report the error until it dereferences NIL you are probably making bad things before that (like in initialization code, for instance:


MODULE Main;

IMPORT SIO;

VAR
 a,b,c: BOOLEAN := b=c ;
BEGIN

 SIO.PutBool(a);
 SIO.PutBool(b); 
 SIO.PutBool(c);

END Main.

) in an uninitialized or zeroed program since you can not predict b and c will be at time of evaluation in a initialization.
It doesn't solve the problem being pragmatical.
Now, if you want to allow ignoring that  isn't very well behaved IMHO. In fact, that's UNSAFE.

For instance the above example prints TRUETRUEFALSE, in old LINUXLIBC6 makes sense?
No, and making nasty assumptions and ignoring errors won't help. The program is simple and wrong.
Thanks in advance

--- El lun, 25/2/13, Rodney Bates <rodney_bates at lcwb.coop> escribió:

De: Rodney Bates <rodney_bates at lcwb.coop>
Asunto: Re: [M3devel] language question -- locals uninitialized or zero?
Para: m3devel at elegosoft.com
Fecha: lunes, 25 de febrero, 2013 12:08



-Rodney Bates

--- lemming at henning-thielemann.de wrote:

From: Henning Thielemann <lemming at henning-thielemann.de>
To: Antony Hosking <antony.hosking at gmail.com>
Cc: m3devel <m3devel at elegosoft.com>
Subject: Re: [M3devel] language question -- locals uninitialized or zero?
Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET)


On Sun, 24 Feb 2013, Antony Hosking wrote:

> I suppose it could, but that would be a space leak.The current implementation sets it to NIL.

I believe that the question was, whether he can rely on the pointer being 
NIL, and I think he cannot.

Yes, he cannot, strictly by the language rules.  Somewhat pragmatically, it seems
a real stretch to imagine why an implementer would choose anything other than NIL,
for any reference type.  Even more pragmatically, I am quite sure we have no variant
of the compiler that uses anything other than NIL.  But to have code that is guaranteed
to survive any future new implementation, give it an explicit :=NIL.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130226/368d3101/attachment-0002.html>