Why does this small C++ code works

aagajaba · 11-07-2009, 10:43 AM

I found this code as the URL/Motto in the profile of a top coder contestant.
I don't know why this code works, I mean internally what is happening.
Also depending on the value of number ( here "195") , the code gives segmentation fault or not.
eg: On my computer it gives seg fault with value 195, but on my friends computer, it doesn't give segfault with this value, but gives seg fault with many other values.
So, in short, I am totally confused and I want to know, how this is working.

Please Help.

Code:

 int main = ( cout << "Hello world!\n", 195 );

smeezekitty · 11-07-2009, 12:34 PM

Quote:

Originally Posted by aagajaba

I found this code as the URL/Motto in the profile of a top coder contestant.
I don't know why this code works, I mean internally what is happening.
Also depending on the value of number ( here "195") , the code gives segmentation fault or not.
eg: On my computer it gives seg fault with value 195, but on my friends computer, it doesn't give segfault with this value, but gives seg fault with many other values.
So, in short, I am totally confused and I want to know, how this is working.

Please Help.

Code:

 int main = ( cout << "Hello world!\n", 195 );

i see why it would seg fault LOL.
the 195 might be a machine code call or jmp instruction.

johnsfine · 11-07-2009, 01:42 PM

I don't see why it should seg fault. It should display the message and set main to 195.

What is the whole program you tested to get the seg fault?

graemef · 11-08-2009, 01:44 AM

Quote:

Originally Posted by aagajaba

So, in short, I am totally confused and I want to know, how this is working.

Please Help.

Code:

 int main = ( cout << "Hello world!\n", 195 );

The comma operator evaluates the left hand instruction discards the result and then evaluates the right hand expression.

So the left hand expression will display "Hello World!" on the screen and throw a new line. The return value is a pointer to the output stream but as I said this will be discarded, the right hand expression is a number which will become the result of the expression, hence 195 will be assigned into your variable.

There is nothing there that would cause a seg fault. Maybe you should show the whole program if you want to know why you are getting a seg fault.

aagajaba · 11-08-2009, 02:18 AM

Quote:

Originally Posted by graemef

The comma operator evaluates the left hand instruction discards the result and then evaluates the right hand expression.

So the left hand expression will display "Hello World!" on the screen and throw a new line. The return value is a pointer to the output stream but as I said this will be discarded, the right hand expression is a number which will become the result of the expression, hence 195 will be assigned into your variable.

There is nothing there that would cause a seg fault. Maybe you should show the whole program if you want to know why you are getting a seg fault.

This is the complete code.
In short, the above code + including header files.
Thanx!

Code:

#include <iostream>
using namespace std;
int main = ( cout << "Hello world!\n", 195 );

smeezekitty · 11-08-2009, 02:20 AM

its a seg fault because its calling the variable main as a function;

graemef · 11-08-2009, 04:28 AM

The following code simplifies your code and hopefully you can see why you are getting a segmentation fault.

Code:

#include <iostream>
int main=(0);

C++ expects its initial function to be called main, what you are doing is create a variable called main assign it a value and that value is assumed to contain the address of the initial function. It tries to run the contents of that address as code and, well thankfully it doesn't it just seg faults.

johnsfine · 11-08-2009, 06:56 AM

Quote:

Originally Posted by graemef

C++ expects its initial function to be called main, what you are doing is create a variable called main assign it a value and that value is assumed to contain the address of the initial function.

I'm pretty sure that value stored in main is not used as that address. The address of main is used as the address of the missing main(), so the value is used as the first opcode.

In the OP's example, the initialization code for global variables is called before main(), so the message is displayed before the seg fault.

graemef · 11-08-2009, 08:06 AM

That sounds correct, but essentially the problem arises with the lack of a proper main function.

ta0kira · 11-08-2009, 12:57 PM

Quote:

Originally Posted by johnsfine

I'm pretty sure that value stored in main is not used as that address. The address of main is used as the address of the missing main(), so the value is used as the first opcode.

It could be that static construction results in the assignment before main gets called, so when main is called (I assume that) either 195 is executed or what's at address 195 is executed. I wouldn't assume that 195 directly causes the segfault; it could causes overwriting of another data area, e.g. static data, and static destruction might subsequently cause the segfault. I'd try it with C, but I have better things to do at the moment...
Kevin Barry

aagajaba · 11-08-2009, 11:52 PM

Quote:

Originally Posted by ta0kira

It could be that static construction results in the assignment before main gets called, so when main is called (I assume that) either 195 is executed or what's at address 195 is executed. I wouldn't assume that 195 directly causes the segfault; it could causes overwriting of another data area, e.g. static data, and static destruction might subsequently cause the segfault. I'd try it with C, but I have better things to do at the moment...
Kevin Barry

Thanx!
I think I understand some of it now.
In C and C++ , before calling main, another function is called which calls main.
So when it might be calling main, it first prints Hello World, assigns 195 at the address where main is pointing.
Now when main is called, all that is seen is 195, which might be some opcode, which is causing seg fault.

paulsm4 · 11-09-2009, 12:41 AM

Hi -

Try the equivalent in C: it won't even compile:

Code:

#include <stdio.h>

int main = (printf ("Hello world\n"), 195);

Also try this:

1. Create a C++ program that has an "int" variable with the same name as an "int" function.

2. Compile and link: you'll find that it builds and runs.

3. Now compile with "g++ -S" to get assembly output.
<= You'll probably find that it's legal ... and that the "int variable" and "int function" probably have *two different names*.

'Hope that helps .. PSM

aagajaba · 11-09-2009, 02:40 AM

Quote:

Originally Posted by paulsm4

Hi -

Try the equivalent in C: it won't even compile:

Code:

#include <stdio.h>

int main = (printf ("Hello world\n"), 195);

Also try this:

1. Create a C++ program that has an "int" variable with the same name as an "int" function.

2. Compile and link: you'll find that it builds and runs.

3. Now compile with "g++ -S" to get assembly output.
<= You'll probably find that it's legal ... and that the "int variable" and "int function" probably have *two different names*.

'Hope that helps .. PSM

I came 2 know 1 important thing.
195 is opcode for return in Pentium processors.
So it works with pentium.
But in core 2 duo, (as is mine), before returning from a function, it seems it is necessary to have an instruction called leave. I am not usre about this though.
So it gives segfault in core 2 duo.

eric.r.turner · 11-09-2009, 06:42 AM

Here's some info that might (or might not!) help. On my computer (AMD Athlon 64 3500+ running Fedora 11) gdb shows that it segfaults in __libc_start_main()

Code:

Program terminated with signal 11, Segmentation fault.
#0  0x001f8a63 in __libc_start_main () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-5.i686 libgcc-4.4.1-2.fc11.i586 libstdc++-4.4.1-2.fc11.i586
(gdb) bt
#0  0x001f8a63 in __libc_start_main () from /lib/libc.so.6
#1  0x08048541 in _start ()
(gdb)

Decompile the executable and see that __libc_start_main is pretty simple:

Code:

objdump --disassemble main
...
080484d4 <__libc_start_main@plt>:
 80484d4:	ff 25 10 99 04 08    	jmp    *0x8049910
 80484da:	68 18 00 00 00       	push   $0x18
 80484df:	e9 b0 ff ff ff       	jmp    8048494 <_init+0x30>
...

The first instruction starts execution at the address obtained from the value stored at address 0x8049910. I'm guessing that's where your program is dying. Would be interesting to see what value is stored at that location (anyone know how to find that out?)

aagajaba · 11-09-2009, 10:27 AM

Quote:

Originally Posted by eric.r.turner

Here's some info that might (or might not!) help. On my computer (AMD Athlon 64 3500+ running Fedora 11) gdb shows that it segfaults in __libc_start_main()

Code:

Program terminated with signal 11, Segmentation fault.
#0  0x001f8a63 in __libc_start_main () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-5.i686 libgcc-4.4.1-2.fc11.i586 libstdc++-4.4.1-2.fc11.i586
(gdb) bt
#0  0x001f8a63 in __libc_start_main () from /lib/libc.so.6
#1  0x08048541 in _start ()
(gdb)

Decompile the executable and see that __libc_start_main is pretty simple:

Code:

objdump --disassemble main
...
080484d4 <__libc_start_main@plt>:
 80484d4:	ff 25 10 99 04 08    	jmp    *0x8049910
 80484da:	68 18 00 00 00       	push   $0x18
 80484df:	e9 b0 ff ff ff       	jmp    8048494 <_init+0x30>
...

The first instruction starts execution at the address obtained from the value stored at address 0x8049910. I'm guessing that's where your program is dying. Would be interesting to see what value is stored at that location (anyone know how to find that out?)

Code:

 objdump -S < obj file name>

this gives you the complete list and you can know what is at that address