Thread: -1 element in struct array but doesnt throw an error

i have a function that searches through a struct array for a piece with co-ordinate x and co-ordinate y. If it finds it it returns the index of the array element if it cant find it it returns -1. i then use that index to address the array to update an element within the struct.

if the index is -1 i WAS then trying to update one of the struct array elements with an index of -1 ie

Code:

index = -1
white[index].taken = true;

i never got an error or program crash in fact i only discovered this when debugging another function last night.
Why did it allow me to do this?
coop

Originally Posted by GReaper

reading memory "backwards" messes with the CPU's cache

Only if memory pointed crosses a line bondary, but this happens in "forward" access too.

Why does C allow you to do this? C has no bounds checking. At all. You can read past the end of an array, or before the beginning. C assumes you know what you're doing. Maybe you know there's something interesting just before the array in memory, C is not going to second guess you. It's undefined behavior though. If you start reading or writing memory outside your variables and arrays, all bets are off. You might overwrite something and corrupt structs used by the memory allocator (which is quite common) or any other values. If you overwrite things on the stack and mangle the return address in a function, and then you're in trouble for sure.

Why doesn't this crash? You haven't overstepped the bounds of the OS yet. The OS sets up a virtual memory environment and maps physical memory pages (on most machines, they're 4k in size) to virtual addresses which is what your C program sees. It also defines whether you can read from, write to or execute code on any of these pages. Unless the array is at the very beginning of a page and no other page is mapped to the space before it, the OS doesn't know anything is wrong if you index an array with -1. Once you do overstep those bounds and leave the page to an empty space in virtual memory, however, the CPU will kick that straight to the OS and the OS will kill usually the program. This is what's referred to a segmentation fault or a page fault.

There's more to it than that, but the point is that there's a lot of memory you can touch and not immediately crash the program. You have to be very careful not to do this, it can cause bugs that can go undetected until something else changes, and then suddenly a program that worked fine for years starts crashing.

so when i have "over filled" an array or gone off the end and the program crashes with the message stack bashing detected i have i assume tried to write somewhere where i shouldn't (the stack?
So i was just "lucky" with my struct array

A simple example why negative indexes are permited:

Code:

int a[] = { 1, 2 };
int *p = &a[1];
int x = p[-1]; // same as *(p - 1) or a[0].

Just as a side note, a lot of c programming is done in a free-standing environment (i.e. No OS at all)

In this case, all bets are off - If you try to write at the wrong address, that address will be written to.

The trick is to make it obvious that you are doing it so that it can be picked up in testing

Code:

for(i =0; i<MAX; i++)
// becomes
for(i =0; i!=MAX; i++)

It still might be a bug, but it is no longer a hard to find bug.

Originally Posted by cooper1200

so when i have "over filled" an array or gone off the end and the program crashes with the message stack bashing detected i have i assume tried to write somewhere where i shouldn't (the stack?
So i was just "lucky" with my struct array

This is actually a different error and not a segmentation fault, but the principle and causes are the same. A common security vulnerability is overwriting an array on the stack, which will allow you to modify things that will allow the user to take control of the program. To combat this, they include a "canary" (as in a canary in the coal mine), a value on the stack that if overwritten then part of the program or the OS can detect that an error has occurred. The principle is the same, though, something accessed memory out of bounds and the OS killed the program.