NEW(): ASSERT vs. Returning NIL

General discussions about working with the Astrobe IDE and programming ARM Cortex-M3, M4 and M7 microcontrollers.

NEW(): ASSERT vs. Returning NIL

Postby 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()?
gray
 
Posts: 51
Joined: Tue Feb 12, 2019 2:59 am

Re: NEW(): ASSERT vs. Returning NIL

Postby 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.
cfbsoftware
Site Admin
 
Posts: 394
Joined: Fri Dec 31, 2010 12:30 pm

Re: NEW(): ASSERT vs. Returning NIL

Postby 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().)
gray
 
Posts: 51
Joined: Tue Feb 12, 2019 2:59 am

Re: NEW(): ASSERT vs. Returning NIL

Postby cfbsoftware » Thu Mar 28, 2019 7:16 pm

Yes.

e.g. SYSTEM.VAL(INTEGER, NIL) = 0.
cfbsoftware
Site Admin
 
Posts: 394
Joined: Fri Dec 31, 2010 12:30 pm


Return to Astrobe for ARM Cortex-M3, M4 and M7

cron