Endian mode and hPutBuf & hGetBuf

[Simon Marlow]

> On Wednesday 08 January 2003  2:32 pm, Simon Marlow wrote:
> > Oops, I lied.  hPutArray and hGetArray work on arrays of=20
> Word8 only, so
> > in order to get non-portable results you need to use=20
> castIOUArray, which
> > is already documented as having undefined behaviour.
>=20
> I guess you must mean it's behaviour has not been defined yet.
> (Or is it's behaviour undefined by definition? :-)
>=20
> I tried to use it recently to save an IOUArray of Word32's to a file
> by castIOUArray'ing it to an IOUArray of Word8's and using hPutArray
> (AFAICS the only possible way to do this using the current library
> functions).
>=20
> It didn't work. For an array of N Word32's using N as the argument
> to hPutArray only gave me the first N/4 Word32's in the file.
> Using 4N gave me an error message about buffers. So I ended up
> not using an IOUArray at all :-(

That's a symptom of the bug that castIOUArray doesn't change the bounds
of he array to reflect the new type, so hPutArray thinks you're trying
to access the array outside its bounds.

The trouble is, to do this properly we'd need to change the type of
castIOUArray, so that it can get hold of the information it needs to
rescale the bounds.  Currently we have

  castIOUArray :: IOUArray ix a -> IO (IOUArray ix b)

perhaps we'd need something like

  castIOUArray :: (C a, C b) =3D> IOUArray ix a -> IO (IOUArray ix b)

where C is some new class that lets you get at the scaling factors for
the types a and b.

This might be overkill.  Alternatively, castIOUArray could take the new
bounds as an argument, or we could have a way to replace the bounds of
an IOUArray/STUArray (unsafeReplaceBoundsIOUArray?).  Comments?

Cheers,
	Simon