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

[edgar at edgarschwarz.de]

easlab at absamail.co.za
> Edgar wrote:-
> > Nope. C is on the stack not on the heap => No initialisation before use.
> * My reference to C being uninitialised, was independant of 'trapping.
> Indeed the C of the *.Mod [I believe] was an 'object', hence heap resident,
I wrote that alredy but nevertheless I will repeat it.
YOUR BELIEF IS WRONG ! My believe is that C is on the stack.

> *  Unless deliberately designing a 'non-deterministic routine', in general
> reading an object/variable before writing/initialising it is an ERROR,
So C itself doesn't need any initialisation. There is only an error if
a field of C is read before write. Any argument for that ?

> > 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.
> 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.
So my guess is:
- The problem was that NEW(iCon) failed because the memory on the heap was
  fragmented and there wasn't any continous space big enough left.
- Fragmentation happens with time and if you open more and more viewers
  over time this happens.
- The Oberon garbage collector collects garbage but can't defragment the heap
  AFAIK.
- So after a reboot this problem is obviously gone because you have an
  unfragmented heap now.
Just a guess but matches the facts I know.

Cheers, Edgar