[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