int *i;
*i=123;
+27
A:
Yes. There is no allocated memory to place the value 123.
Like initializing a variable like int is not guaranteed to be 0, an int* isn't guaranteed to be a safe address.
It also could potentially lead to data corruption.
Daniel A. White
2010-01-01 14:52:22
it is not guaranteed to cause a segfault though. It could by happenstance point to a writable location.
Evan Teran
2010-01-01 21:28:17
+30
A:
It can, but there again it could do anything - it exhibits what the C Standard calls "undefined behaviour".
anon
2010-01-01 14:53:42
It could even erase your hard drive. Not bloody likely, but it could.
Adam Rosenfield
2010-01-01 15:04:27
Not as unlikely as it might seem. I always used to take the floppies out of my old Z80 CP/M box before I ran some newly assembled code to prevent exactly this happening!
anon
2010-01-01 15:07:46
It could erase your hard drive as far as the C language is concerned. These days a process doing undefined behavior is still subject to the operating system's security rules, so chances are slim. Still, if you've used `sudo` recently...
Jason Orendorff
2010-01-01 15:11:47
Unless you have a user account just to sandbox your C compiler, your user privileges are probably enough to delete anything you care about on your hard drive, even if it can't be fully erased.
Steve Jessop
2010-01-01 17:22:52
Remember, the compiler is allowed to generate anything at all for undefined behavior, so starting a game of pong is allowed!
Tim Williscroft
2010-01-05 00:46:06
+1
A:
int *i; This allocates a memory for pointer but this variable is not initialized so it's value is totally random. Then you dereference it so you have a random address and perform a write to this place in the memory but 1) you don't know where the place is 2) this place probably is not yours. You can fix it with initialization like int * i = ( int* ) malloc( sizeof(int) )
Gaim
2010-01-01 15:08:46
The cast from `void*` to `int*` is unnecessary in C and bad practice. `int *i = malloc(sizeof(int));` is perfectly sufficient.
Chinmay Kanchi
2010-01-01 16:33:44
+3
A:
Rough odds on a 32-bit operating system:
- Odds to trigger a hardware exception: 99.9995%
- Odds to corrupt program state: 0.0005%
- Odds to accidentally hit the right memory location: 1 in 2 billion
Estimates only to demonstrate orders of magnitude. Relevant only for a Release build. If it does corrupt program state then the odds it will do so consistently climb to close to 100%. A good compiler makes the hardware exception odds 100% in the Debug build. Get a good compiler.
Hans Passant
2010-01-01 15:13:08
Yes, i will be initialized to a random value. But who said anything about a linear distribution?
Martinho Fernandes
2010-01-01 15:21:12
I think you mean a "uniform" distribution. But if that code was executed just after calling a function that left a pointer in that stack location, then odds are actually very good that it points to valid memory.
Adam Rosenfield
2010-01-01 15:31:11
+2
A:
Yes, the code you posted can cause a segmentation fault. You've got a pointer which is uninitialized (doesn't point to any known location) and you then use it to store something. Where does the 'something' go? Good question, to which there is no consistent answer.
You need to initialize that pointer. For example:
int target = 0;
int *i = ⌖
printf("target=%d\n", target);
*i=123;
printf("target=%d\n", target);
I hope this helps.
Bob Jarvis
2010-01-01 16:28:07