On 11/10/06, roconnor@theorem.ca
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.