Page 1 of 1
NEW(): ASSERT vs. Returning NIL
Posted: Wed Mar 27, 2019 3:57 am
by gray
The Oberon Report (2016) states for NEW(): "Failure of allocation results in p obtaining the value NIL." (6.4 Pointer Types). Storage.Allocate() has an ASSERT to check for heap overflow (which halts execution as per the standard Error module). Is Storage.Allocate() an exact representation of the compiler's internal allocation code, including the ASSERT (or the halting effect thereof)? If yes, what is the reasoning here not to follow the Report (ie. return NIL), leaving the error handling to the caller of NEW()?
Re: NEW(): ASSERT vs. Returning NIL
Posted: Wed Mar 27, 2019 9:42 am
by cfbsoftware
Good question. Currently you can modify Storage to return NIL. We''ll do what is necessary in the next maintenance release (possibly with a new option) to allow either backward compatibility or conformance with the language Report.
Re: NEW(): ASSERT vs. Returning NIL
Posted: Wed Mar 27, 2019 12:32 pm
by gray
Is NIL represented as 0 (zero), ie. does 'returning NIL' mean assigning zero to 'p' in Storage.Allocate()? (That's what I would infer from Storage.Deallocate().)
Re: NEW(): ASSERT vs. Returning NIL
Posted: Thu Mar 28, 2019 7:16 pm
by cfbsoftware
Yes.
e.g. SYSTEM.VAL(INTEGER, NIL) = 0.