jacob navia said:
Casey Hawthorne a ?crit :
Changing the meaning of the array indexing brackets "[ ]" to do bounds
checking and then using another notation for array indexing without
bounds checking, say "[| |]", might help minimize buffer overruns.
By default, previous programs would have bounds checking turned on,
unsless explicilty turned off.
The lcc-win C compiler implements this. It is called "operator
overloading".
You can define your own [ ] operators, and the compiler will call
your function that can do bounds checking in the array.
[...]
Does lcc-win allow a [] operator to be defined for existing types that
already have a built-in [] operator? For example, can I do something
like this (I'm not sure of the syntax)?
int operator[](int *arr, size_t index)
{
return /* something */;
}
I suspect the answer is no.
I think the OP is suggesting changing the semantics of the existing
built-in [] operator, so that existing code gains bounds checking
with no modifications to the source.
Of course implementations are already allowed to do this, even
without operator overloading. All cases in which a bounds check
would fail invoke undefined behavior anyway, so the implementation
is free to generate code that detects the error.
The overhead would be substantial, since you'd need fat pointers to
retain bounds information for function parameters. And it would
break some existing code whose behavior is, strictly speaking,
undefined, but that works in practice. The most obvious examples
are the "struct hack" (which could be modified to use the C99 feature
that replaces it, but the point is to avoid changing the source), and
code that treats a multidimensional array as a one-dimensional array.
Code that avoids these odd corners of the language could certainly
benefit from a bounds checking implementation. And in fact I believe
such implementations exist, though I don't know if they go so far as
to implement fat pointers to enable checking on pointer parameters.
(At the very least, *testing* code under such an implementation could
be instructive.)