Anyone can solve my C Query ??

In C Programming, with TC++ 3.0 and Windows 98 SE, the output of the following code would be 657. Why So ?? Also note that output would change with LINUX.





main()


{


printf("%d",main) ;


}





We have this as an explain the reason question in our Post Graduation C examination and I am unable to find satisfactory answer in the search engines.

Anyone can solve my C Query ??
U may get surprised to know that it's a garbage value, but this value is not guaranteed, u're using Turbo C++ IDE compiler, so u're getting 657, use Linux u'll get some other value.





So, again I'm saying '657' is garbage. More specifically, the program invokes undefined behavior, and anything at all might happen. On the system you are using at the moment, "anything at all" appears to be "print 657," but that is not guaranteed.





The program exhibits undefined behavior for two reasons,


and "peculiar behavior" for two more:





- It calls a variadic function without a prototype in


scope. Functions that take a variable number of


arguments -- like printf() -- must be properly


declared before use, or undefined behavior results.


The best way to declare printf() is to #include


%26lt;stdio.h%26gt;.





- It uses the "%d" conversion specifier with a value


that is not an `int'. `main' in the printf() call


is a pointer to the function named `main', and a


function pointer is not an `int'. When you tell


printf() to expect an argument of one type (`int')


and actually supply something different (function


pointer), undefined behavior results.





- It fails to end its final (only) line of output with


a newline character '\n'. On some implementations,


the output may not appear at all unless each line


ends with a newline.





- It "drops off the end" of the `int'-valued function


main() without returning an `int' value. If the


environment tries to use the value returned by main()


as an indication of the program's success or failure


(most environments do this), great confusion can


result if main() fails to return a value.
Reply:This is odd, and not what I would expect in the environments I have worked in. You are interpreting the address of a function as an integer, and it is coming out very small.





I suspect it has to do with integer size. The size of an integer is not defined by C, and can be 16 bits. I bet that on this architecture addresses are 32 bits and integers are 16 bits, so this is picking up the top 16 bits of the address field.





So what is this address? Looking at the bit pattern (binary)


1010010001, this probably is a page boundary where the executable is stored, and the first function listed is main.
Reply:%d is the...symbol for integers, so what you see int he output is probably the numerical value of the word main(I think)





Try replacing %d with %s, and main with "main".


As far as I remember, thats what you need for string output in C.








It might be different in Linux because Linux might be (might be(might be)) using a different character code.
Reply:Here are two possibilities for to grapple with: (unless you just want to convey that advanced degree on ME).





When you use %d, you are asking it to print an integer. For one system, and integer might be an 8 bit byte, in another system, it might be a 16 bit byte... and in a third system, it might be a 32 bit byte. For Windows 98SE, it's just 16 bits.





When you ask to print an integer of the starting address of the routine main (which is a bizare thing to do), you could get just about any darn thing to print. Of course, when you recompile under linux, it will display some different sort of bizzare answer. TRY IT with both systems.





Good luck