-1
/* C program illustrating how 2-dimensional arrays
   are passed in C
*/

//Prototype
#include <stdio.h>
void printArray (int arr[][10]);


int main () 
{
  /* declare the 2-dimensional array */
  int table [5][10];
  int i, j;  /* loop indices */

  /* initialize the array */
  for (i = 0; i < 5; i++)
    for (j = 0; j < 10; j++)
      table[i][j] = 10*i + j;

  printArray (table);

  printf ("table element [3][7]:  %d\n", table [3][7]);
  printf ("table element [3][12]:  %d\n", table [3][12]);
  printf ("table element [3][-4]:  %d\n", table [3][-4]);

  return 0;
}

//Definition
void printArray (int arr[][10])
{
  int a, b;
  printf ("The 2-dimensional array is:\n");
  for (a = 0; a < 5; a++)
    {
      for (b = 0; b < 10; b++)
        printf ("%5d", arr[a][b]);
      printf ("\n");
    }
}

Why there is still values showing up in this arrays:

printf ("table element [3][12]:  %d\n", table [3][12]);
printf ("table element [3][-4]:  %d\n", table [3][-4]);

Output is 42 and 26 respectively. I want to know how does it happen? The array is only limited to [5][10] eh?

pritam
  • 2,452
  • 1
  • 21
  • 31
  • 1
    Basically in C accessing invalid memory (e.g beyond the bounds of an array) is undefined behaviour. – kaylum Dec 04 '19 at 02:36
  • 2
    `[3][12]` and `[3][-4]` are out of bounds accesses, causing undefined behaviour. Even though the elements are contiguous in memory, the language rules limit subscripting of an array to elements of that array (which applies to the sub-array `table[3]`) – M.M Dec 04 '19 at 02:37
  • Then why does it shows concise results like 42 and 26, not just any other gibberish values? – Asher Manangan Dec 04 '19 at 02:38
  • 3
    42 and 26 are gibberish! Why do you think they are not? Could you have worked out it was 42 or 26 from theory alone? And try to add some more unrelated code or run it on a different machine and you may find the values are different. Or not. That's what **undefined** means. – kaylum Dec 04 '19 at 02:39
  • 2
    *"I want to know how does it happen?"* - There is no language-supported reason why it happens. You lost that support as soon as you invoked *undefined behavior* by accessing `arr[3]` out of it's {0..9} happy place. Regarding "why does it shows concise results". Concise in what context ? On your platform with your toolchain and runtime implementation, it *appears* to be concise to... something. You would be unwise to gamble that as conclusive universally. That is the epitome of confusing *observed* behavior with *defined* behavior. The latter will lead to the former; the reverse not so much. – WhozCraig Dec 04 '19 at 02:42

1 Answers1

1

This is called Undefined Behavior

Generally, when undefined behavior is encountered, anything might happen, the machine might crash, freeze, do some really weird stuff, or even sometimes as in your case, work fine. This is because C doesn't check out of bound errors and just let the machine do what it needs to do, and arrays consist of just values and their corresponding addresses which only utilize raw memory, so implementing bound checking mechanism is not possible.

O Yahya
  • 366
  • 2
  • 7