[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NEW & extending redefinition



> > > From: Guy Laden <guy@math.tau.ac.il>
> > > Date: Tue, 15 Apr 1997 01:31:57 +0300 (GMT+0300)
> > > 
> > > >   NEW (v, 0)
> > > ...
> > 
> > > 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.  
> > 
> > You are saying that you _had_ applications that wanted to allocate a
> > zero length array in a perfectly sane context?  Correct?
> 
> Yes. 
> 
> The limitation was needlessly cluttering my class invariants and
> various procedure preconditions.
> 
> However perhaps a compile-time warning for the case where things can 
> be statically determined would be useful.

Ok.  From this time on this will be the official behaviour of NEW for
any OOC compiler:

Using NEW to create an open array with a negative length in one of its
dimensions will trigger a run-time error.  A length of zero is
permitted, even if no read operation on such an array is possible
later on.  Writing NEW(a,0) will trigger a compile-time warning, just
like an array definition of the form "ARRAY 0 OF T".

NEW(v) or NEW(v, ...) will always return a non-NIL value in `v'.  If
it can't obtain the required amount of memory it'll signal a run-time
error and abort the program.

-- mva