NEW(): ASSERT vs. Returning NIL

General discussions about working with the Astrobe IDE and programming ARM Cortex-M0, M3, M4 and M7 microcontrollers.
Post Reply
gray
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

NEW(): ASSERT vs. Returning NIL

Post by gray » Wed Mar 27, 2019 3:57 am

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()?

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: NEW(): ASSERT vs. Returning NIL

Post by cfbsoftware » Wed Mar 27, 2019 9:42 am

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.

gray
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Re: NEW(): ASSERT vs. Returning NIL

Post by gray » Wed Mar 27, 2019 12:32 pm

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().)

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: NEW(): ASSERT vs. Returning NIL

Post by cfbsoftware » Thu Mar 28, 2019 7:16 pm

Yes.

e.g. SYSTEM.VAL(INTEGER, NIL) = 0.

Post Reply