Re (2): [Oberon] n-o trap analysis confuses me

[easlab at absamail.co.za]

Edgar wrote:-
> I called http://pathology with NO on 486 without problems.
> Now some comments to your trap in ImgIcon:
> > My reasoning is that:
> > 1. C must be initialised before:
> Nope. C is on the stack not on the heap => No initialisation before use.
> 
This thread has become complicated: handling different related topics 
on different levels - and I'm going to add more !

* My reference to C being uninitialised, was independant of 'trapping.
Indeed the C of the *.Mod [I believe] was an 'object', hence heap resident,
and my simple example was an integer, hence stack resident.

*  Unless deliberately designing a 'non-deterministic routine', in general
reading an object/variable before writing/initialising it is an ERROR,
and as I remember flagged as a warning by some compilers.
Therefore I believe it unlikely that the *.Mod under consideration
[you've deleted my thread back-ground] did so. It remains to be seen
what I've missed in thinking that C was read without being first initialised.

> That said I feel that ImgIcon is an example of optimistic programming:
> In rare cases it could be possible that e.g.
> 	obj := Gadgets.FindPublicObj("Icons.Picture");
> or
> 	NEW(iCon);
> fail and then you will get a -14.

As Peter wrote:-
} Can you elaborate a little Edgar.

Does this mean that you too believe that C was not initialised ?
If so, I find it necessary to make a BIG story about. 

This whole matter is very strange: I used the system for years without 
the Trap.  Then it appeared from some months, and then dissapeared
without me knowing the reason.   So I start considering exotic causes.
Like the 'heap load' or a kind of Y2K effect.

In fact I KNOW that all my boxes are infested with the 'russian flag 
boot virus'. So next time I reboot, I'll set the date back a month to
when I had the Trap, as a further test.

== Chris Glur