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]

Sterten wrote:

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
Surely you mean "but x happens to be <0 or >98"
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]

"Sterten" <st*****@aol.co m> wrote in message news:20******** *************** ****@mb-m05.aol.com...

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((unsigne d) i < 99);
t = R[i];

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 ?

[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((unsigne d) i < 99);
t = R[i];

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.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Barry Schwarz]

On Sat, 24 Jul 2004 17:26:10 -0700, "Ricardo Gibert"
<no**********@c ox.net> wrote:

"Sterten" <st*****@aol.co m> wrote in message news:20******** *************** ****@mb-m05.aol.com...

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((unsigne d) 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[i];

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...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[Keith Thompson]

Barry Schwarz <sc******@deloz .net> writes:

On Sat, 24 Jul 2004 17:26:10 -0700, "Ricardo Gibert"
<no**********@c ox.net> wrote:

"Sterten" <st*****@aol.co m> wrote in message
news:20******* *************** *****@mb-m05.aol.com...

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((unsigne d) 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[i];

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).

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ricardo Gibert]

"Keith Thompson" <ks***@mib.or g> wrote in message news:ln******** ****@nuthaus.mi b.org...

Barry Schwarz <sc******@deloz .net> writes:

On Sat, 24 Jul 2004 17:26:10 -0700, "Ricardo Gibert"
<no**********@c ox.net> wrote:

"Sterten" <st*****@aol.co m> wrote in message
news:20******* *************** *****@mb-m05.aol.com...
>
> 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((unsigne d) 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[i];

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.

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

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[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...

--
Emmanuel

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.