Re: array bounds check option

[Per Bothner <bothner@cygnus.com>]

Craig Burley <burley@gnu.org> writes:
> I'd suggest -farray-bounds-check, because "bounds" might be too
> general ("range" certainly is).
>
> E.g. consider whether someone might want an option to check the
> range of values assigned to "enum"s, or types declared with
> explicit ranges (a la Pascal).

In a language with range types, if you check array indexes,
I think you would normally want to "range check" also on values
coerced to ranges.  That catches possible subscript errors earlier.
Also, if we can assume that index expressions whose types are
ranges have values that are actually within the range of its type,
then we can easily optimize away range checks when the range of
the actual index is a sub-set of the array index range.

Thus in normal use, "check array subscript" would imply "check
cast to range type".  That is reasonable for Chill, and (I
believe) Pascal.  Ada I'm not sure about.  A common flag
(both in the sense of one that does it all, and in the sense of
the flag most commonly used!) does not preclude finer control
(such as -fbounds-check -fno-conversion-bounds-check).

> consider whether someone might want an option to check the 
> range of values assigned to "enum"s

That should probably also be implied by -fbounds-check - but
only for enums that have a dense range with values that
always increase by one.

> So I'd say -fsubscript-bounds-check is appropriate only if
> you're putting a check on each ARRAY_REF node (or whatever
> its called), while -farray-bounds-check is appropriate only if
> you're checking the computed offset into the array against
> the overall bounds of the array.

That is reasonable.  But I think -fbounds-check should imply
one of -fsubscript-bounds-check or -farray-bounds-check
depending on the language and strictness mode.  In C or C++,
and traditional Fortran, it might imply -farray-bounds-check.
In Java, Chill, and -pedantic Fortran it might imply
-fsubscript-bounds-check.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner