Expecting segmentation fault

[Bhavith]

Hi ,

#include <iostream>
using namespace std;
int main()
{
 char a[1];
 a[1]= 'a'; // expecting segmentation fault 

 char b[1];
 b[2] = 'b'; // expecting segmentation fault , output as expected i.e I got seg //fault

 return 0;
}

Hi guys please let me know why segmentation fault is not coming

[TheIdeasMan]

Looks like Undefined behaviour to me: anything could happen.

I found this in the standard § 5.7 note 5

[quote=c++11 draft standard]..... If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behaviour is undefined.[/quote]

When I ran it using the gear icon, I did not get a segfault.

There might be compiler options to warn against out bounds subscript.

[Moschops]

You'll get a segFault when you try to read or write memory that the operating system thinks does not belong to you. In this case, clearly you are not writing to memory that the operating system thinks doesn't belong to you, so there is no segFault.

In this case, I expect that the in-memory layout of your variables is something like this:

ARRAY a (one byte) :: MANY EMPTY PADDING BYTES :: ARRAY b (one byte)

So when you try to write beyond the end of the array a, you are writing into the empty padding bytes. This region of memory was allocated to your program, so the OS has no problem with you writing to it. The OS doesn't know anything about sizes of your arrays or anything like that; it just knows the memory you're allowed to use, and the memory you're not allowed to use.

When you then try to write beyond array b, you are writing into memory that was NOT given to you by the OS, so it objects.

You can check the memory address of a and b and examine the memory between them to check the layout. The memory layout might not be what I guessed, but whatever it is, you're not getting a segFault when you write to a[1] because that memory space is part of the memory the OS is happy for you to write over.

[Bhavith]

But if I do a[2]='a' then segmentation fault comes .

[Moschops]

So what have we learned? We have learned that the memory location at a[1] is memory that the OS gave you, and the memory at a[2] is memory the OS did not give you.

Can you imagine a way for that the be the case? You will have to actually think a little bit about how it could be possible.

Seriously, I told you how it works. You have now learned that a[2] indicates a memory location the OS believes you're not allowed to write to, and a[1] indicates a memory locationthe OS believes you are allowed to write to. Maybe the array a is at the end of your memory, and a[1] is an empty padding byte, and a[2] is memory the OS didn't give to you. Start thinking.

[TheIdeasMan]

@Bhavith

These sort of discussions / questions really don't lead anywhere. It's obviously bad practise, so don't do it. It's easy to code so these things don't happen, so go with that.

Interesting in your bio, you are "Software Developer on C, C++ , C# , Java Programming", so why questions such as these ?

[ne555]

> expecting segmentation fault
that was your mistake, it's undefined behaviour.


> It's easy to code so these things don't happen
I don't think so.
Also, they are hard to detect sometimes.


> In this case, clearly you are not writing to memory that the operating system
> thinks doesn't belong to you, so there is no segFault.
¿clearly? considering what you say later, I think this is backwards.
because you've got no segFault, then you may suppose that...

Edit: ¿is is guaranteed that `a' would be before `b'? ¿or that the program has access to all the memory in between?

[abhishek486]

because this is related to upper case ,lower case

i guess so

[Moschops]

Edit: ¿is is guaranteed that `a' would be before `b'? ¿or that the program has access to all the memory in between?

There are no guarantees about how the objects will be laid out in the memory. The C++ standard does (since c++11) discuss a memory model, but where to put variables is left to the implementer, and how the operating system hands out memory to processes and keeps an eye on that memory is nothing to do with C++.

because this is related to upper case ,lower case

It has nothing at all to do with upper case and lower case.

[kalki]

In C there is no bound checking to see if the subscripts used for an array exceeds the size of the array.Data entered with a subscript exceeding array size will simply be placed in memory outside the array or probably to of the other data.

Thus, to see to it that we do not reach beyond the array size, is entirely the programmer's botheration and not the compiler's.

Where as about seg fault:You'll get a segFault when you try to read or write memory that the operating system thinks does not belong to you.