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