Re: NEW & extending redefinition

[Guy Laden <guy@math.tau.ac.il>]

> I recently noticed that NEW(v,n) doesn't check that `n' is a valid
> length, or that it was actually able to allocate the required amount
> of heap space.  This raises two questions:
> 
> a) What is a valid length?  A negative number is illegal and should
> abort the program like any other failed run-time check.  But is a
> length of zero allowed?
> 
> Example:
>   VAR v: POINTER TO ARRAY OF CHAR;
>   ...
>   NEW (v, 0)
> 
> Should this trigger a run-time check?  Without pathological 0-length
> arrays all iterations over open arrays are known to be executed at
> least once (i.e., are REPEAT UNTIL loops), saving an extra test for
> loops like "FOR i := 0 TO LEN(a)-1 DO".

Oberon/F triggers a COMPILE-TIME check for the above, and a 'value out-of-range'
runtime error when the '0' was replaced with a variable containing 0.
To be honest I dont much like the above behaviour. I remember a few times I had
to add the the checks for zero anyway.
Can anyone think of other reasons except the efficiency gain?
On the other hand I think compatibility with ETH is very important...

> b) Should a failed NEW() return NIL or trigger a run-time check?  Most
> code simply assumes that NEW will always bring back a new pointer, so
> implementing the second alternative might be better.

Oberon/F returns NIL. In code that doesnt check, this usually causes a 
run-time trap soon afterwards anyway.  With this in mind I'd prefer
to have the flexibility of being able to manually checking for NIL.

The Oberon/F compiler is based on OP2 but they have changed it siginificantly so
I'm not sure the above is 'ETH compliant'.

Regarding "extended" and "standard" modes for the compiler, if extended means
Oberon/F compatibility and standard means ETH compatibility then fwiw I'd vote
for it.

Regards,
Guy.