C strange int array pointer

Question

int *array; //it allocate a pointer to an int right?
    array=malloc(sizeof(int); //allocate the space for ONE int right?
    scanf("%d", &array[4]);  //must generate a segmentation fault cause there is not allocated space enough right?
    printf("%d",array[4]); //it shouldn't print nothing...

but it print 4! why?

"Must generate a segmentation fault" - no, there's no such guarantee. — Oliver Charlesworth, Jun 14 '14 at 17:44
Accessing out of range array element is undefined behavior, it may or may not crash. And there are already many questions that answer this. — Rohan, Jun 14 '14 at 17:44
but do you agree with me that i'm writing beyond the end of array? — user3740872, Jun 14 '14 at 17:47
C is not like - for example - Java or C# where an access outside an array throws an error. Instead it's a case the spec chooses not to define a behavior for (undefined behavior) and the implementation is free to do whatever it likes to do. In this case apparently just writing to the memory as you ask it to do, even if you didn't reserve space for it so things may go badly later. — Joachim Isaksson, Jun 14 '14 at 17:47
Just to mention, you should do type-cast for malloc like this : `array=(int)malloc(sizeof(int))`. — , Jun 14 '14 at 17:49
@JayPanchal: Actually, in `C` that is not recommended. See: [Do I cast the result of malloc?](http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc) — Blastfurnace, Jun 14 '14 at 17:51
@JayPanchal Er... `int*` maybe, but casting malloc isn't necessary in `C`. — Joachim Isaksson, Jun 14 '14 at 17:51
if i want to create an array of int and allocate memory for one int i use int *array; array=malloc(sizeof(int); then if i want to read more int and dinamically allocate memory for it can i use: int i=0; while(array){ scanf("%d",&array[i]); i++; array=realloc(array,(i+1)*sizeof(int)); }? — user3740872, Jun 14 '14 at 17:52
@JayPanchal: Let me guess: You are stuck on MSVC++ and try to compile your C code with it... — Deduplicator, Jun 14 '14 at 17:55

score 2 · Answer 1 · answered Jun 14 '14 at 17:45

Reading or writing off the end of an array in C results in undefined behavior, meaning that absolutely anything can happen. It can crash the program, or format the hard drive, or set the computer on fire. In your case, it just so happens to be the case that this works out perfectly fine, probably because malloc pads the length of the allocated memory for efficiency reasons (or perhaps because you're trashing memory that malloc wants to use later on). However, this isn't at all portable, isn't guaranteed to work, and is a disaster waiting to happen.

Hope this helps!

score 0 · Answer 2 · answered Jun 14 '14 at 17:45

0

Cause the operating system happens to have this memory you have asked. This code is by no means guaranteed to run on another machine or another time.

answered Jun 14 '14 at 17:45

sestus

1,875
2
16
16

score 0 · Answer 3 · answered Jun 14 '14 at 20:09

C doesn't check your code for getting of boundaries of an array size, that depends to the programmer. I guess you can call it an undefined behavior (although it's not exactly what they mean when they say an undefined behavior because mostly the memory would be in a part of the stack or the heap so you can still get to it. When you say array[4] you actually say *(array + 4) which is of course later translated to *(array + 4*sizeof(int)) and you actually go to a certain space in the memory, the space exists, it could be maybe a read-only, maybe a place of another array or variable in your program or it might just work perfectly. No guarantee it'll be an error, but it's not what undefined behavior. To understand more about undefined behavior you can go to this article (which I find very interesting).

C strange int array pointer

3 Answers3