unsafeShift operations for Data.Bits

[Samuel Bronson]

On 11/10/06, roconnor at theorem.ca <roconnor at theorem.ca> wrote:
> On Fri, 10 Nov 2006, Donald Bruce Stewart wrote:
>
> >> uncheckedFoo - under certain conditions that arn't checked for, this
> >> routine may produce well defined, but unspecified behavior. (as in, the
> >> behavior might depend on something compiler or architecture specific)
> >
> >    uncheckedShift
> >    uncheckedRead/Write
>
> Doesn't a uncheckedRead/Write potentially crash my machine and/or
> overwrite arbitrary points of memory?  It seems like at least
> unwiseunsafeWrite could break the dynamic semantics by breaking the static
> semantics in a random and machine dependent way.  And still a
> uncheckedRead can segfault my machine.  I submit that any instruction that
> can segfault my machine is unsafe.

I was thinking the same thing.

Also, note that unchecked shifts *don't* necessarily have well-defined
behaviour. I mean, no nasal daemons or anything[1], but the values
produced when out-of-range shift values are passed in could be
anything (anything non-bottom, that is), couldn't they? In the back of
K&R (section A7.8), it says "The result is undefined if the right
operand is negative, or greater than or equal to the number of bits in
the left expression's type." This sounds to me like it could give you
random junk, but not crash your program unless your program does
something stupid with the result value. So, it would violate
referential transparency, maybe, but I don't think it matters that
much... I mean, you aren't supposed to pass out-of-range shift amounts
to uncheckedShift*.

[1] That is, C's "undefined behaviour", where anything, including
having daemons fly out your nose or cthulu being summoned, could
happen according to the C standard.