Why doesn't the below program crash? [duplicate] - c++

This question already has answers here:
Accessing an array out of bounds gives no error, why?
(18 answers)
Closed 2 years ago.
I have written a small program but couldn't understand why it does't crash when a is accessed out of bounds?
#include <iostream>
using namespace std;
int main()
{
double *a = new double[4];
a[0]=1;
a[1]=2;
a[2]=3;
a[3]=4;
cout <<"size of double:"<<sizeof(double)<<endl;
a[100]=100; // why is it not crashing here?
return 0;
}
Could someone explain me whats happening here? Shouldn't this crash at a[100]=100?

Why doesn't the below program crash?
From perspective of C++: Because the behaviour of the program is undefined. The program is neither guaranteed to crash nor to not crash. Nor are there any other guarantees about the behaviour.
From perspective of the operating system: Assuming the compiler did not remove the access due to having detected undefined behaviour, it probably didn't crash because that memory happened to be mapped for the process. In general, it is not safe to assume that all buffer overflows could be detected.

Related

Pointer takes elements bigger than its size in c++ [duplicate]

This question already has answers here:
Accessing an array out of bounds gives no error, why?
(18 answers)
Closed 10 months ago.
When creating a pointer using new keyword or <stdlib.h>'s malloc, and put its size 0; what ever is the index number it doesnt give an error and works. ( i am not sure if this works if the size bigger then 0, because some times when i allocate a memory block and place an element outside its range program crashes).
My question : is this a c++ thing? Or just from my compiler? Is it safe to use it for arrays i don't want to limit it with specific size. Because i am thinking to use this in my game to make unlimited world generation and save it ( Not all terrain just the breakable and placable objects)
#include <iostream>
using namespace std;
int main() {
int* x = new int[0];
x[100] = 0;
cout << x[100];
return 0;
}
is this a c++ thing? Or just from my compiler?
It's a bug in your program. The behaviour of the program is undefined.
Is it safe to use it
It is not safe. The program is broken.

How will this code affect the memory management? [duplicate]

This question already has answers here:
What is the purpose of allocating a specific amount of memory for arrays in C++?
(5 answers)
Closed 5 years ago.
#include<iostream>
using namespace std;
int main()
{
char a[]="robert";
cin>>a;
cout<<a;
}
So size of a is now fixed as 7 bits as intuitive. Now if I read something as "qwertyuiop" into 'a' which is larger than 7 bits, it is expected to show overflow. However nothing such happens and it prints the output normally. What's going on here?
Writing out of the bounds is an undefined behaviour.
In this case looks ok, but what happens if...
#include<iostream>
using namespace std;
int main()
{
char a[5];
char b[7];
cin >> a;
cin >> b;
cout << a << endl;
}
Input:
kingkong
monkeyhunter
Output:
kingkmonkeyhunter
They are mixed up!
You should be careful with arrays in C++, it could be no visible effects if you try to write out of bounds.
The operating system (with the help of the processor) defines a region of memory to which your application is allowed to read/write. When you read outside what you are expected, the processor triggers a hardware exception which is caught by your operating system and this triggers the termination of you application.
However, reading outside an array does not necessarily read outside the boundary of your application (you could for example write/read to another variable of your own code). As an example, at the end of your memory region, you usually have the program stack in reverse order.
C++ specifies the reading/writing outside the range of your array as undefined behavior. In this case, it may crash or not in a 'random-like' fashion.

Deallocating memory using delete keyword - C++ [duplicate]

This question already has answers here:
Undefined, unspecified and implementation-defined behavior
(9 answers)
Closed 6 years ago.
I was solving an online exercise related to de-allocating memory pointed to by pointer using delete keyword in C++. Following is my code.
#include<iostream>
#include<string>
#include<conio.h>
int main()
{
double *ptrDouble = new double;
*ptrDouble = 22;
std::cout << "\nValue of ptrDouble = " << *ptrDouble << std::endl;
delete ptrDouble;
std::cout << "Value of ptrDouble = " << *ptrDouble << std::endl;
getch();
}
So according to the online site where i am solving this exercise,
If you use the delete keyword on the pointer , the memory will be
deallocated and therefore the contents will not be available to your
application any longer. Attempting to access the contents will cause
your application to crash due to a memory violation.
But when i try to print the value of the ptrDouble after deallocating the memory, the program doesn't crashes, instead a garbage value is printed on the console.
Question is, am i doing something wrong or that online site is wrong about whether program should crash or not ?
PS. I am using visual studio 2015 community.
Accessing freed memory leads to undefined behavior. Crashing or reading garbage both fall into that category. Whether or not the program will actually crash depends on whether that particular block of memory was returned to the OS or merely made available for reuse.

Access to out of array range does not give any error [duplicate]

This question already has answers here:
Accessing an array out of bounds gives no error, why?
(18 answers)
Closed 7 years ago.
Why this:
#include <iostream>
using namespace std;
int main() {
int a[1] = {0};
a[2048] = 1234;
cout << a[2048] << endl;
return 0;
}
does not give any compile-time error? (gcc 4.9.3)
Because this is legal C++.
You can try to dereference any pointer, even if it's not allocated by your program, you can try to access any cell of an array, even if it is out of bounds, the legality of an expression doesn't depend on the values of the variables involved in that expression.
The compiler doesn't have to run any static analysis to check whether you'll actually cause undefined behaviour or not, and shouldn't fail to compile if it assumes that you will (even when it is obvious that you will).
The problem is that you can't check all possible array access at compile-time (that would be way too expensive), so you'd have to arbitrarily draw a line somewhere (the problem being the word "arbitrarily", that wouldn't fit well in the standard).
Hence, checking that you won't cause undefined behaviour is the responsability of the programmer (or of specific static analysis tools).
Access to out of array range does not give any error
This is just because you were unlucky. :) What you can call it is "Undefined Behavior". Compiler is not doing any bound check on arrays, and what you are trying to do in statement a[2048] = 1234;is to write a memory location on stack, which is unused.

theory and problems on memory usage [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is a stack overflow error?
look the code below.
#include <iostream>
using namespace std;
void leave(double as){
cout<<as;
leave(as);
}
int main(){
double x=1234.5;
leave(x);
cout<<"hellow";
}
When this code executes their is no way to stop. it should print the value x over and over again. But practically, this works for about 20 secs and close automatically. It doesn't print the line hellow. What is the reason for it? In windows task manager I can realize that the memory used with the application will increase. but I have allocated memory for x within the main function only, so will the function allocate memory for x over and over again. Is this type of situation called a memory leak? if its so what lines should be added to prevent it?
If I change the code as below it shows the word hellow without going through the function over and over again:
void leave(){
leave();
}
int main(){
leave();
cout<<"hellow";
}
How to explain these situations?
Every call to leave() results in adding a little information to the stack. When you call it recursively, the stack grows until it runs out of space, and the operating system terminates the application. In the second example, presumably the compiler optimized out the function that did nothing.