Mirsad Todorovac wrote:
Perhaps it's worth a spare attribute or two, such as
attribute(norange);
and
attribute(mustrange);
(the names are not obligatory part of suggestion).
They'd allow finer-grained range checking control than {R+} and {R-}, per object or per entity. Of course, if that's not too much trouble for Frank.
I'm not sure. In the ideal case, it would take "only" one flag for each ordinal type. (Those flags are a limited "resource" by the backend. Currently, we have some left, but we shouldn't waste them.)
I'm not sure if it's worth the effort, since we have a clean (conformant arrays, schemata) and a BP-compatible (MaxVarSize) alternative, and such an attribute also wouldn't be compatible to anything.
I hope it's not adding too much complexity to the compiler. In ideal case, every particular type of range check might be turned on/off independently.
Quite a bit of very tedious work ...
I've read about some researches telling how most often errors are so called "of by one" errors, and IMHO is thus a vital part of chasing bugs out of the program, triggering an error exactly where it occurs, not segfaulting miles of code later.
Yes, that's the basic idea of range-checking. Of course, for "emulated" variable-sized arrays (whether 0 or MaxVarSize), the compiler has no way to know the actual size, so we can forget about it. All other cases should be caught be range-checking in the future.
Frank