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...
Related
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 5 months ago.
This post was edited and submitted for review 5 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
#include<stdio.h>
#include<conio.h>
void main()
{
int i;
for ( ;i<=5;i++)
{
printf ("%d",i);
}
}
Why I am getting this output? output = 012345
I did not expecting any output. because as i didnt intilise i, so from where he is going to start?
if i will be intilise by a undefined value, why I am getting the same output as many times i run the code?
int i;
i is uninitialized and holds an indeterminate value. 0 is one of the many values it can contain.
for ( ;i<=5;i++)
In both i<=5 and i++ you read i that has an indeterminate value. The compiler is allowed to assume that you never do that and may produce assembler code that does anything. The program therefore has what is called undefined behavior.
printf ("%d",i);
Here you print i whatever it may be. If i happened to contain 0 when you left it uninitialized - and if the compiler was "kind" enough to let your failure to initialize i through without producing an executable that crashes (or worse), then the loop will step i from 0 to 6. When it reaches 6, the condition, i<=5, will be false and the loop will end. Only for the values when i is less than, or equal to, 5 will printf ("%d",i); be reached.
Note that the program may do different things when you run it multiple times because it has undefined behavior. i may suddenly be -98723849 when you run the program and then your loop will print the values from -98723849 up to 5.
I did not expecting any output. because as i didnt intilise i, so from where he is going to start?
As mentioned - the program could do just about anything because you didn't initialize i and then read from it. In your case, it seems i contained a 0 and that the program appears to behave as-if you initialized it to 0. Again, this is "pure luck" - no matter how many times in a row it displays the same behavior.
if i will be intilise by a undefined value, why I am getting the same output as many times i run the code?
Because the program has undefined behavior. It may repeat the same thing over and over again for many years. It's a ticking bomb that may suddenly explode one day.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I need to memorize how much memory I allocated with realloc().
Help me
if(!array)
array=(Type*) calloc(1,sizeof(Type));
else
array=(Type*)realloc(array,(cont+1)*sizeof(Type));
array[cont].setName(....);
cont++;
It doesn't work: after firt insert, it say: Access violation
I initialized the cont = 0 in the constructor of my class and freed memory in the destructor.
See the comments added to your code:
int count=0;
if(!array)
array=(Type*) calloc(count,sizeof(Type*); // Problem:
// missing )
// use sizeof(Type)
// calling calloc with count being zero
// so you do not allocate any memory
// use 1 instead of count
array[c].setName(EditName->Text);
c++;
count++;
array=(Type*)realloc(array,count*sizeof(Type*)); // Problem:
// use sizeof(Type)
so it should look:
int count=0;
if(!array)
array=(Type*) calloc(1,sizeof(Type));
array[c].setName(EditName->Text);
c++;
count++;
array=(Type*)realloc(array,count*sizeof(Type));
The variable c must be initialized to zero before running this code
Likewise array must be nullptr before running this code
EDIT
There seem to be one more problem if you intend to run this code several times (which I assume you do).
This line:
array=(Type*)realloc(array,count*sizeof(Type));
^^^^^
Don't use count here as you always sets count to zero
The line shall be:
array=(Type*)realloc(array,c*sizeof(Type));
In general there seems to be no real use of count
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Hi i new learn here please explain below question i m learning on my own from many days i do have some dout with malloc function .please help i know this site it not for beginners but i couldn't get alternative way to find the solution
1) p=malloc(0) // what will it return ?when i calculate size using sideof operator it throw 4 byte?
2) int *p=malloc(4) // when i scan string it throw 0 why sir?
3) *p=2 // while p is store in heap
scanf("%d",*p)//why *p is not possible to scanf here *p why p only?
4) int *p=(int*)malloc(20*sizeof(int))
for(i=0;i<5;i++)
p[i]=i+1;
free(p);
//now after free i am still get same previos value.. why not garbage coz malloc default value is garbage?
5) int main()
{
int *p;
p=(int*)malloc(4);
printf("%d\n",*p); // even here i am getting 0 why nt garbage?
}
Thank you sir
"Freeing" means "making available for allocation again". There is no automatic deleting / overwriting of memory contents because it would negatively impact performance. If you want the area to be set to a value, you have to do it yourself before you call free(). That would be bad practice in release code, though (for anything else but data security reasons).
The same is true when allocating the memory: It does not get set to any specific value, but contains what it happened to contain previously. If you want it to be initialized to zero, use calloc(). If you want to set it to a specific other value, use memset() after you allocated it. Again, consider that this has performance implications, and is usually not necessary.
As for your last question, "%d" is for signed integers. For unsigned, use "%u".
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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Array index out of bound in C
Can a local variable's memory be accessed outside its scope?
C no out of bounds error
I am trying out this code snippet,
#include <stdio.h>
main(){
int a[2],i;
a[5] = 12;
for(i=0;i<10;i++){
printf("%d\n", a[i]);
}
return 0;
}
It gives me output :
1053988144
32767
0
3
0
12
-1267323827
32716
0
0
Why a[5] is accessible ? Shouldn't it through RunTime Error?
C doesn't have bounds-checking on array access, so no it shouldn't. There is nothing in the language stopping you from attempting to read every (virtual) address you can imagine, although often the operating system and/or computer itself will protest, which might generate some kind of exception. Note that just because you "can" (it compiles and run, seemingly without any ill effects), that doesn't mean the program is valid or that it "works". The results of invalid memory accesses are undefined behavior.
int a[2]; means "allocate memory that is 2 * sizeof(int)"
a[5] is syntactic sugar for *(a + 5), which point to an area of memory a + (5 * sizeof(int)). So 3 * sizeof(int) past the end of your array. Where is that? Who knows?
Some languages do bound checking, and I have heard of some C compilers that can do it as well, but most do not. Why not do bound checking? Performance. And performance is a major reason for using C in the first place. But that's OK, because C programmers are good programmers and never go beyond the bounds of an array. (hopefully)
No control is performed on index bounds. This is simply the way C works.