On Wed, 21 Jun 2006 16:12:48 +0000 (UTC), Dimitri Maziuk <[EMAIL PROTECTED]> wrote:
>George Neuner sez: >> On Mon, 19 Jun 2006 22:02:55 +0000 (UTC), Dimitri Maziuk >><[EMAIL PROTECTED]> wrote: >> >>>Yet Another Dan sez: >>> >>>... Requiring an array index to be an integer is considered a typing >>>> problem because it can be checked based on only the variable itself, >>>> whereas checking whether it's in bounds requires knowledge about the array. >>> >>>You mean like >>> subtype MyArrayIndexType is INTEGER 7 .. 11 >>> type MyArrayType is array (MyArrayIndexType) of MyElementType >>> >> >> If the index computation involves wider types it can still produce >> illegal index values. The runtime computation of an illegal index >> value is not prevented by narrowing subtypes and cannot be statically >> checked. > >My vague recollection is that no, it won't unless _you_ explicitly code an >unchecked type conversion. But it's been a while. You can't totally prevent it ... if the index computation involves types having a wider range, frequently the solution is to compute a wide index value and then narrow it. But if the wider value is out of range for the narrow type you have a problem. Using the illegal wide value in a checked narrowing conversion will throw a CONSTRAINT_ERROR exception - it doesn't matter whether you access the array directly using the wide value or try to assign the value to a variable of the narrow index type. Using the wide value unchecked will access memory beyond the array which is not what you wanted and may cause a crash. The point is really that the checks that prevent these things must be performed at runtime and can't be prevented by any practical type analysis performed at compile time. I'm not a type theorist but my opinion is that a static type system that could, a priori, prevent the problem is impossible. George -- for email reply remove "/" from address -- http://mail.python.org/mailman/listinfo/python-list
