checking array indices

[Sterten]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
....
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

Is there a way to prevent this ?
Is there a program or debugger or compiler which
checks the array indices before executing the command and
eventually issues an error-warning when the index is out of range ?

 

[Martin Ambuhl]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious

becomes unpredictable.

Is there a way to prevent this ?

Yes. Don't write bad code that attempts to access beyond the bounds of
the array.

 

[Ricardo Gibert]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);
t = R;

 

[Emmanuel Delahaye]

int R[99];

and then later access it with
x=R[r];C[x]=7;

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);
t = R;

Bare in mind that assert() is a debug tool. It helps to trap impossible
or forbidden by-design statuses. But it is not designed to trap user
level errors.

BTW, on many development systems, the assert() macro is simply ignored
at release time, due to the definition of the global NDEBUG macro.

 

[Barry Schwarz]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

Is there a way to prevent this ?
Is there a program or debugger or compiler which
checks the array indices before executing the command and
eventually issues an error-warning when the index is out of range ?

<<Remove the del for email>>

 

[Sterten]

I'm thinking just at a program which traverses
the .c source program and includes
a line
if(xxx<0 || xxx>99)printf("index out of range in line yyy")

directly before every line yyy containing
R[xxx] , which it finds.
Then the new converted .c program
can be compiles and executed when problems with array indices are suspected.

Seems not very difficult to write such a program, someone must have done it
already ?!?

 

[Emmanuel Delahaye]

Sterten wrote on 25/07/04 :

I'm thinking just at a program which traverses
the .c source program and includes
a line
if(xxx<0 || xxx>99)printf("index out of range in line yyy")

directly before every line yyy containing
R[xxx] , which it finds.
Then the new converted .c program
can be compiles and executed when problems with array indices are suspected.

Seems not very difficult to write such a program, someone must have done it
already ?!?

Sounds to be a good idea, but it might more complicated if pointers are
involved, what happens when you 'pass an array' to a function for
example...

 

[Keith Thompson]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

No, there is no negative value of type int that yields a value less
than 99 when converted to unsigned int. (There might be exotic
representations where this isn't the case.)

But I'd still be more comfortable with

assert(i >= 0 && i < 99);

(assuming that assert is a good way to do the check in the first
place).

 

[Ricardo Gibert]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

No, there is no negative value of type int that yields a value less
than 99 when converted to unsigned int. (There might be exotic
representations where this isn't the case.)

The idea that, "There might be some exotic implementation where this isn't the case," hadn't occurred to me. I can't imagine what it
would be like. Hmmm.

In any case, on two's complement machines, a good optimizing compiler will convert "i >= 0 && i < 99" to "(unsigned) i < 99", since
this saves several assembly instructions. The cast from int to unsigned consumes zero machine cycles on two's complement machines.
In an assert, this is not important, but anywhere else, this is a nice trick. I just thought I throw it into my post to make people
think.

But I'd still be more comfortable with

assert(i >= 0 && i < 99);

For an assert() or any code that is serious about being readable for that matter, your way is much better.

 

[Sterten]

Sterten wrote on 25/07/04 :

I'm thinking just at a program which traverses
the .c source program and includes
a line
if(xxx<0 || xxx>99)printf("index out of range in line yyy")

directly before every line yyy containing
R[xxx] , which it finds.
Then the new converted .c program
can be compiles and executed when problems with array indices are suspected.

Seems not very difficult to write such a program, someone must have done it
already ?!?

Sounds to be a good idea, but it might more complicated if pointers are
involved, what happens when you 'pass an array' to a function for
example...

I can see no principal difference, except
that the function-definition-line with
Array[] should be discarded of course.

hmm, what's with Array[function(x)] =whatever; ?
you'd have to do something like

y=function(x); if(y<Range1 or y>range2)printf("error");
Array[y]=whatever;


but then, this can be nested to several levels...
:-(

--Guenter.

 

[Keith Thompson]

The idea that, "There might be some exotic implementation where this
isn't the case," hadn't occurred to me. I can't imagine what it
would be like. Hmmm.

I was thinking vaguely of something involving padding bits, for
example, where INT_MAX and UINT_MAX are both 2**31-1 (perhaps because
the underlying hardware doesn't support unsigned integer arithmetic).
It's unlikely in real life, and I'm not even sure whether it would
cause the specified results.

[...]

For an assert() or any code that is serious about being readable for
that matter, your way is much better.

On the other hand, if the more obscure form results in faster code,
and it actually turns out to be a bottleneck, it might make sense to
use it -- but I'd encapsulate it in a well-commented macro. (On the
other other hand, since assert() is effectively ignored if NDEBUG is
defined, optimization probably doesn't matter much anyway.)

 

[Barry Schwarz]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

No, there is no negative value of type int that yields a value less
than 99 when converted to unsigned int. (There might be exotic
representations where this isn't the case.)

This is only true in the "common" situation where the absolute value
of INT_MIN is only half of UINT_MAX. The standard does not require
this. It is possible for these values to be equal but opposite in
sign. It would be legal on a 32-bit system for
INT_MAX=UINT_MAX=pow(2,31)-1 and INT_MIN=-INT_MAX. (There is no
requirement that an unsigned int use the now irrelevant sign bit to
extend its range of values.) In fact, any exponent value between 31
and 16 would be compliant.

On any system where INT_MIN <= -UINT_MAX, the 99 int values
between -UINT_MAX and -UINT_MAX+98 would satisfy the assert but still
invoke undefined behavior.

But I'd still be more comfortable with

assert(i >= 0 && i < 99);

(assuming that assert is a good way to do the check in the first
place).

<<Remove the del for email>>

 

[Sterten]

On the other hand, if the more obscure form results in faster code,

and it actually turns out to be a bottleneck, it might make sense to
use it -- but I'd encapsulate it in a well-commented macro. (On the
other other hand, since assert() is effectively ignored if NDEBUG is
defined, optimization probably doesn't matter much anyway.)

I don't know "assert", will have to look this up, so maybe I misunderstand the
above.

But speed is no problem in the debug-version. Later, when it runs correctly
I will remove all this checking in the final version.

 

[Ricardo Gibert]

On Sat, 24 Jul 2004 17:26:10 -0700, "Ricardo Gibert"

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

No, there is no negative value of type int that yields a value less
than 99 when converted to unsigned int. (There might be exotic
representations where this isn't the case.)

This is only true in the "common" situation where the absolute value
of INT_MIN is only half of UINT_MAX. The standard does not require
this. It is possible for these values to be equal but opposite in
sign. It would be legal on a 32-bit system for
INT_MAX=UINT_MAX=pow(2,31)-1 and INT_MIN=-INT_MAX. (There is no
requirement that an unsigned int use the now irrelevant sign bit to
extend its range of values.) In fact, any exponent value between 31
and 16 would be compliant.

On any system where INT_MIN <= -UINT_MAX, the 99 int values
between -UINT_MAX and -UINT_MAX+98 would satisfy the assert but still
invoke undefined behavior.

A cast from int or char to unsigned does not cause undefined behavior.

 

[E. Robert Tisdale]

when I define

int R[99];

and then later access it with

x=R[r]; C[x]=7;
...

but x happens to be < 0 or > 99,
then the program's behaviour becomes unpredictable.

Is there a way to prevent this?
Is there a program or debugger or compiler
which checks the array indices before executing the command and
eventually issues an error-warning when the index is out of range?

The GNU C compiler used to do this and some compilers still do:

http://www.cray.com/craydoc/manuals/S-5212-50/S-5212-50-manual.pdf

http://techpubs.sgi.com/library/tpl...e=/SGI_Admin/Porting_Guide/sgi_html/ch04.html

http://docs.rinet.ru/InforSmes/ch35/ch35.htm

I used Google

+"C compiler" +"check array bounds"

to search for

+"C compiler" +"check array bounds"

 

[Giorgos Keramidas]

The idea that, "There might be some exotic implementation where this
isn't the case," hadn't occurred to me. I can't imagine what it would be
like. Hmmm.

An architecture on which the least significant bit it used as the sign
of a value combined with a C compiler which coerces int values to
unsigned by clearing the sign bit or even by shifting it to one of the
value bits.

Then -3 would be represented as 00000111 and would be coerced to
unsigned as 00000110 which would be +3 but still less than 99.

In any case, on two's complement machines, a good optimizing compiler
will convert "i >= 0 && i < 99" to "(unsigned) i < 99", since this saves
several assembly instructions. The cast from int to unsigned consumes
zero machine cycles on two's complement machines. In an assert, this is
not important, but anywhere else, this is a nice trick. I just thought I
throw it into my post to make people think.


For an assert() or any code that is serious about being readable for
that matter, your way is much better.

--

 

[Barry Schwarz]

On Sat, 24 Jul 2004 17:26:10 -0700, "Ricardo Gibert"

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

No, there is no negative value of type int that yields a value less
than 99 when converted to unsigned int. (There might be exotic
representations where this isn't the case.)

This is only true in the "common" situation where the absolute value
of INT_MIN is only half of UINT_MAX. The standard does not require
this. It is possible for these values to be equal but opposite in
sign. It would be legal on a 32-bit system for
INT_MAX=UINT_MAX=pow(2,31)-1 and INT_MIN=-INT_MAX. (There is no
requirement that an unsigned int use the now irrelevant sign bit to
extend its range of values.) In fact, any exponent value between 31
and 16 would be compliant.

On any system where INT_MIN <= -UINT_MAX, the 99 int values
between -UINT_MAX and -UINT_MAX+98 would satisfy the assert but still
invoke undefined behavior.

A cast from int or char to unsigned does not cause undefined behavior.

Obviously, but once the unsigned value has passed the assert, the
signed negative value is used as an array index and that does cause
undefined behavior.


<<Remove the del for email>>

 

[Ricardo Gibert]

On Sat, 24 Jul 2004 17:26:10 -0700, "Ricardo Gibert"

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

You must mean x < 0 or x >= 99 in the above.

You can try this:

assert((unsigned) i < 99);

Why the cast. If i contains a sufficiently large negative value, your
assert will be true but your next statement will invoke undefined
behavior.

t = R;

No, there is no negative value of type int that yields a value less
than 99 when converted to unsigned int. (There might be exotic
representations where this isn't the case.)

This is only true in the "common" situation where the absolute value
of INT_MIN is only half of UINT_MAX. The standard does not require
this. It is possible for these values to be equal but opposite in
sign. It would be legal on a 32-bit system for
INT_MAX=UINT_MAX=pow(2,31)-1 and INT_MIN=-INT_MAX. (There is no
requirement that an unsigned int use the now irrelevant sign bit to
extend its range of values.) In fact, any exponent value between 31
and 16 would be compliant.

On any system where INT_MIN <= -UINT_MAX, the 99 int values
between -UINT_MAX and -UINT_MAX+98 would satisfy the assert but still
invoke undefined behavior.

A cast from int or char to unsigned does not cause undefined behavior.

But I'd still be more comfortable with

assert(i >= 0 && i < 99);

(assuming that assert is a good way to do the check in the first
place).

Obviously, but once the unsigned value has passed the assert, the
signed negative value is used as an array index and that does cause
undefined behavior.

Okay, I see I managed to misunderstand even though it should have been clear. Sorry.

In the event that the condition "INT_MIN <= -UINT_MAX" were true, you would be correct. Something that would exhibit such undefined
behavior would be a cast from long long to unsigned long as an example, but I don't think "INT_MIN <= -UINT_MAX" is ever true, since
unsigned is guaranteed to occupy the same amount of storage as an int.

 

[Sterten]

when I define

int R[99];

and then later access it with

x=R[r]; C[x]=7;
...

but x happens to be < 0 or > 99,
then the program's behaviour becomes unpredictable.

Is there a way to prevent this?
Is there a program or debugger or compiler
which checks the array indices before executing the command and
eventually issues an error-warning when the index is out of range?

The GNU C compiler used to do this and some compilers still do:

http://www.cray.com/craydoc/manuals/S-5212-50/S-5212-50-manual.pdf


http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=bks& srch=&fname=/SGI_Admin/Porting_Guide/sgi_html/ch04.html

http://docs.rinet.ru/InforSmes/ch35/ch35.htm

I will check these later offline.
I'm using gcc3.2 .
Although I also asked for a compiler-referrence, I think
I'd prefer a program to convert my
..c-source to another .c-program with
bounds-checking

I used Google

+"C compiler" +"check array bounds"

to search for

+"C compiler" +"check array bounds"

hmm, I had used combinations with "array indices" rather than "array bounds"
and
found a referrence to the compaq-compiler

 

[Fred L. Kleinschmidt]

when I define
int R[99];
and then later access it with
x=R[r];C[x]=7;
...
but x happens to be <0 or >99 , then the program's behavious
becomes unpredictable.

Is there a way to prevent this ?
Is there a program or debugger or compiler which
checks the array indices before executing the command and
eventually issues an error-warning when the index is out of range ?

You do not show us how array C is declared. Of course, if x<0 there will
be a problem, but we can't tell about >99 unless you declare C as
C[100]. Perhaps you mean r<0 or r>98?

Using assert is fine when you are developing and testing, but unless you
can ABSOLUTELY guarantee that 0<=r<=98 and no value of R is ourside the
bounds of a legal index for C, you should probably use a run-time check:
if ( r<0 || r>98 ) ...
Also, using a magic number like '98' is not a great idea - set a macro
to that value instead.

Note also that assert() will not just generate a warning message; it
will abort the program on an error. Using an 'if' test will allow the
program to write a warning message and attempt to recover, assuming you
can figure out how to do that.

Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 (206)544-5225