The Data.Array.* hierarchy is unsafe (or,
Segfaulting for fun and profit)
Iavor Diatchki
iavor.diatchki at gmail.com
Tue Dec 5 13:00:43 EST 2006
On 12/5/06, Simon Marlow <simonmarhaskell at gmail.com> wrote:
> Nils Anders Danielsson wrote:
> > On Mon, 04 Dec 2006, Simon Marlow <simonmarhaskell at gmail.com> wrote:
> >
> >
> >> An implementation is entitlesd to assume the following laws about these
> >> operations:
> >>
> >> range (l,u) !! index (l,u) i == i -- when i is in scope
> >> inRange (l,u) i == i `elem` range (l,u)
> >> map index (range (l,u)) == [0..rangeSize (l,u)]
> >
> >
> > Even if these laws are not satisfied, is the implementation really
> > allowed to segfault? I would have guessed that the array operations
> > should still be equivalent to some pure Haskell program (e.g.
> > undefined).
>
> To me, the wording "An implementation is entitled to assume..." implies that
> there are no obligations on the implementation should the assumption not hold -
> no obligation to yield _|_ or any other behaviour.
>
> > If "laws not satisfied => any behaviour OK" were the correct
> > interpretation, then it would be OK for the Array implementation to
> > wipe all your files at the first encounter of a broken Ix law... ;)
>
> Yup. That's not quite as bad as in C, where it's ok for an implementation to
> wipe all your files if you overflow the int type...
>
> Cheers,
> Simon
Still, this is pretty bad, and raises questions about the safety of
Haskell programs in general. It seems unsatisfactory that if a
programmer makes a mistake in the definition of an 'Ix' instance, then
there are no guarantees about the behavior of their program at all...
I though that implementations did not assume anything about the
user-specified instances. Are there other classes for which GHC
assumes something about the instances? If so this should be
documented in bold letters with lots of flashing red lights :-)
-Iavor
More information about the Libraries
mailing list