Array indexing size [duplicate] - c

This question already has answers here:
Why doesn't my program crash when I write past the end of an array?
(9 answers)
Closed 7 years ago.
I am getting confused with an array code.
According to me the program should raise an error but it's working fine. The code :
#include<stdio.h>
#include<conio.h>
void main()
{
int a[1],n,i;
clrscr();
printf("Enter the length");
scanf("%d",&n);
for( i=0;i<n;i++)
{
scanf("%d",&a[i]);
}
for(i=0;i<n;i++)
{
printf("%d ",a[i]);
}
getch();
}
Here the array size is 1 but when I enter the length 5 then it works fine : the program show all 5 elements that i have entered.
This is the output screen.

Accessing array out of bounds causes undefined behavior. Anything can happen including the outcome you are observing. In this case you are overwriting some objects stored after the array. They are just not used in this particular case and your program doesn't crash.
Such bugs are really hard to debug. It works fine now, but might start to fail, for example, when different compiler is used. Memory analyzer can help detecting such bugs. It will detect some invalid memory accesses, even if they do not cause a crash.

When you have defined int a[1], only space for one int is allocated on the stack. Any access beyond array bound causes undefined behavior. Therefore, the code is wrong according to the C standard.
In your case, the program is accessing some space beyond the array and by the chance of luck you didn't end up yourself with a segmentation fault.

Related

storing more elements into an array with lesser size behaving not as expected [duplicate]

This question already has answers here:
Are normal Arrays also dynamic? [duplicate]
(3 answers)
Closed 2 years ago.
int a[5];
for(int i=0;i<12;i++)
{
printf("enter element #%d: ",i);
scanf("%d",&a[i]);
}
I expected this to give me an error, but didn't give
It does not take the input when the value of i is 8 i.e., for the 9th element. It just jumps when i=8
When you write past the bounds of an array, you invoke undefined behavior. That means the compiler makes no guarantees regarding what the program will do. It may crash, it may output strange results, or it may appear to work properly.
Just because the program could crash doesn't mean it will.
in your for loop ,your final value of control is 11 and the size of your array is 5,so you fill in the array 11 elements and you array contains only 5 boxes in memory ,your answer is like this :
#include<stdio.h>
int main()
{
int a[5];
for(int i=0;i<5;i++)
{
printf("enter element #%d: ",i);
scanf("%d",&a[i]);
}
}

How does arrays bypass its declared length [duplicate]

This question already has answers here:
How dangerous is it to access an array out of bounds?
(12 answers)
Why doesn't my program crash when I write past the end of an array?
(9 answers)
Array index out of bound behavior
(10 answers)
No out of bounds error
(7 answers)
Closed 3 years ago.
I was making practises on the logic of arrays in c and my thought on the array length declaration was unformattable if you declare an array length to be 10 integers, that array could not keep 20 integers in memory but when I tested it I saw that I was completely wrong
int main(){
int i;
int arr[10];
for (i = 0;i<20;i++){
arr[i] = i;
}
for (i = 0;i<20;i++){
printf("%d \n",arr[i]);
}
}
I was expecting to see 10 printed numbers but it prints out 20 could someone explain how is it possible?
C and C++ don't have explicit bounds checking on array sizes. When you read/write past the end of an array, you invoke undefined behavior.
With undefined behavior, your program may crash, it may output strange results, or (as in your case) it could appear to work properly. Also, making a seemingly unrelated change such as adding an unused local variable or adding a printf for debugging can change how UB manifests itself.
Just because a program may crash doesn't mean it will.

What happens after the end of character array in c? [duplicate]

This question already has answers here:
Segmentation Fault doesn't come up immediately after accessing out-of-bound memory
(5 answers)
Closed 7 years ago.
What's stored after the end of character array? I was assuming there would be some random garbage but it did not print anything after the end while looping 10 times.
char a[] = "Pencil";
int i;
for (i = 0; i < 10; i++)
{
printf("%c", a[i]);
}
so the character array a has the size of 7. And for loop looped until 10th position which are 3 more values looped through. But it did not print anything or Error. What's going on here?
Accessing beyond the end of an array in C is undefined behavior. Your program could continue running unchanged or it could crash horrifically depending on what is stored past the end of the array. The compiler makes no guarantees about what is stored there - it could be useless memory or it could be critical to your program.
Accessing an array element beyond the array-length invokes undefined behavior which means anything could happen.

Crash when trying to make an array overrun [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I read this paragraph in c the complete reference book
C has no bounds checking on arrays. You could overwrite either end of
an array and write into some other variable's data or even into the
program's code. As the programmer, it is your job to provide bounds
checking where needed. For example, this code will compile without
error, but it is incorrect because the for loop will cause the array
count to be overrun.
#include <stdio.h>
int main(){
int count[10], i;
/* this causes count to be overrun */
for(i=0; i<15; i++) count[i] = i;
for(i=0; i<15; i++) printf("%d ",count[i]);
return 0;
}
and when I try the code it gives me
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
And then a run time error was displayed on the screen. The error was
array.exe has stopped working
My question is : What is the type of that error? And does it mean that my IDE checks the bounds of the array?
C doesn't check array idexing, it does only simple pointer-arithmetic. That is, the standard defines the operation array[i] as array + i.
Depending on the resulting memory address of that computation, many things can occur:
The address points to the location of a local variable of the function: You modify the local variable. For example:
int main()
{
int array[10];
int a = 0;
array[11] = 22;
printf(a%i,a); /* Prints 22 */
}
Remember that the point here is that buffer overrun has undefined behaviour. My example could not work, because the compiler is free to reorder the variables layout during compilation, for memory-aligment and optimising purposes.
The address points to the location of a global variable (Thats a very big indexing/jump, but can occur): The effect is the same as in the local variable case.
The address points to the location where the subroutine stores the return address: Many architectures stores the return address of a function in a register, but if the architecture stores it in the stackframe of the function... WOW. TRY TO DEBUG THAT!!! :)
The address goes out of the memory space of the process: Modern operative systems always check memory accesses to prevent this, so when this happens the OS kicks you in the ass and throws an exception.
Finally note that things are only applicable in release compilation. In debug mode the compiler adds a lot of code to check this kind of things to throw (Provide) a comprehensible and easy-debuggeable exception.
For example: When allocating dynamic arrays, windows debug-heap first fills the memory space that will be used with a flag which says that memory space is ready to use, but it doesn't contains any data: Thats the hexspeak 0xBADF00D. After this, malloc retrieves the memory location, adding hexspeaks around the array to provide bounds checking.
See this article for a complete explanation.
The moment the first loop reaches i=10, you enter the realm of undefined behaviour (since you're writing past the end of count). From that point on, anything can happen.
Your IDE had nothing to do with it. The OS killed your program because it tried to access memory that didn't belong to it.
This type of error is usually known as an access violation.
That's fine - and the point of the article you have read...
What you are supposed to do is limit the for loop so that it only runs from 0 to 9.
Or, if you really need 15 items, expand the array to take them...

VirtualBox, GCC and Malloc not giving intuitive answer [duplicate]

This question already has answers here:
How dangerous is it to access an array out of bounds?
(12 answers)
Closed 9 years ago.
I am having a odd issue running scientific linux in VirtualBox when compiling this:
#include <stdlib.h>
#include <stdio.h>
int main(void) {
int *arr;
arr = malloc(sizeof(int)*3);
arr[6]=5;
printf("%d", arr[6]);
return 0;
}
my expectation is that I should get garbage when printing out this arr[6] because I have not allocated enough memory for that space.
However, I will compile it with gcc
gcc main.c -o MainTest
then it will output
5
I may be a bit confused but shouldn't the number be some random number
I may be a bit confused but shouldn't the number be some crazy garbage number.
Why? You wrote 5 there. Of course, you wrote into "out of bounds" space, which is an issue. How an implementation should deal with that is not specified by the C standard, which is the point of undefined behavior, but if it just plain does it, what will (generally) happen is either you are still within the process's address space, or else the OS will hand you a segmentation fault (aka. memory access violation) at runtime. Note that this is not determinable at compile time and may vary from run to run and system to system (more points about undefined behavior).
If you are still within the process address space, you still have a significant problem, because you may have overwritten something that was allocated for some other purpose; C will not protect you from that and this can produce very nasty hard to solve bugs.
Have a look at this link :
Sample Code
What i have observed is *arr is storing the starting address of the array and as you are initializing a[6]=5 whats happening is arr+6 the sixth location in the memory from starting is getting filled up with the value you have put and at the time of printing as it is a valid address its printing the value in the address
Update 1:
As long as the value is not modified by other process it outputs the value in that address space.

Resources