Thread: Size of Main() ?

A function is probably seen as a "void", and I think (in C++ at least) void has a size of 1.

--
Mats

Originally Posted by Elysia

What's that about you can't call main?
You can, but it's probably undefined.

Eh, it's against the C++ standard to call main(), directly or indirectly. I think it's because some platforms implement main() in such a way that it cannot be called recursively, or something like that. I can't remember exactly.

A function is probably seen as a "void", and I think (in C++ at least) void has a size of 1.

Indeed -- look at this!

Code:

$ cat sizeofmain.c
#include <stdio.h>

int main() {
    printf("main: %lu\n", (unsigned long)sizeof(main));
    printf("cast: %lu\n", (unsigned long)sizeof((int (*)(void))main));
    printf("void: %lu\n", (unsigned long)sizeof(void));
    printf("&main: %lu\n", (unsigned long)sizeof(&main));
    return 0;
}
$ ./sizeofmain
main: 1
cast: 8
void: 1
&main: 8

"main" is of type void, but &main is of type int (*)()! That's amazing. I always thought that main and &main were interchangeable, as indeed they are in the case of function pointers.

Code:

void func(void) {}

void (*p)(void);

p = func;
p = &func;
p();
(*p)();

Interesting, indeed.

Indeed. I wonder if sizeof(void)==1 is a GNU extension. http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html

4.17 Arithmetic on void- and Function-Pointers

In GNU C, addition and subtraction operations are supported on pointers to void and on pointers to functions. This is done by treating the size of a void or of a function as 1.

A consequence of this is that sizeof is also allowed on void and on function types, and returns 1.

Anyway.
http://c0x.coding-guidelines.com/6.5.3.4.html

1131 85) When applied to a parameter declared to have array or function type, the sizeof operator yields the size of the adjusted (pointer) type (see 6.9.1).

But what makes a "function type"? . . . . I'm not sure what this has to do with it: http://c0x.coding-guidelines.com/6.3.2.1.html

732 Except when it is the operand of the sizeof operator54) or the unary & operator, a function designator with type “function returning type” is converted to an expression that has type “pointer to function returning type”.

It would seem that "main" is of function type, and "&main" is of function pointer type. Interesting. I thought they were identical.

I'm working on a 64-bit computer at the moment, as you may have guessed. However, I have no idea why the sizeof a function is 1 and the sizeof a function pointer is 8 (or whatever). Any suggestions as to why this is?

Compiler extension. The code, according to the standard, requires a diagnostic. If you're using gcc, -pedantic will cause the required diagnostic to be issued. While you can't take the size of a function in standard C, you can, of course, take the size of a function pointer, e.g. sizeof &main.

(edited)
But you apparently knew that; I guess I didn't reload the page before I posted this.

Originally Posted by dwks

I always thought that main and &main were interchangeable,

They are not, but function is automatically casted to its pointer if needed


as array is casted to the pointer to the first element

So it is one way cast

Indeed, an implicit conversion of sorts.

I guess I'll have to stop telling people that main and &main are exactly the same.

I tried compiling with full warnings, and got a warning, as cas indicated. I also discovered that this is an error in C++.

Code:

$ gcc -W -Wall -ansi -pedantic -g sizeofmain.c -o sizeofmain
sizeofmain.c: In function ‘main’:
sizeofmain.c:4: warning: invalid application of ‘sizeof’ to a function type
sizeofmain.c:6: warning: invalid application of ‘sizeof’ to a void type
$ g++ -W -Wall -ansi -pedantic -g sizeofmain.cpp -o sizeofmaincpp
sizeofmain.cpp: In function ‘int main()’:
sizeofmain.cpp:4: error: ISO C++ forbids applying ‘sizeof’ to an expression of function type
sizeofmain.cpp:5: error: ISO C++ forbids taking address of function ‘::main’
sizeofmain.cpp:6: error: invalid application of ‘sizeof’ to a void type
sizeofmain.cpp:7: error: ISO C++ forbids taking address of function ‘::main’
$

Some of those errors are from taking the address of main() -- which is invalid in C++, as I suspected. When I use another function instead of main, the errors reduce to

Code:

$ g++ -W -Wall -ansi -pedantic -g sizeofmain.cpp -o sizeofmaincpp
sizeofmain.cpp: In function ‘int new_main()’:
sizeofmain.cpp:4: error: ISO C++ forbids applying ‘sizeof’ to an expression of function type
sizeofmain.cpp:6: error: invalid application of ‘sizeof’ to a void type
$

which amounts to the same as the C warnings. Interesting, interesting, interesting.

Originally Posted by brewbuck

I hate this sort of language. "X shall not be done." Right. You gonna make me? And you shall not eat cherries on Wednesday evening. The point is, what happens if I break the rule? They don't even say "It's undefined." They say... nothing at all on the question.

It's like a law saying "Murder shall not be committed" without specifying the penalty, without even specifying that "The penalty is undefined."

C99:

4. Conformance
1 In this International Standard, ‘‘shall’’ is to be interpreted as a requirement on an implementation or on a program; conversely, ‘‘shall not’’ is to be interpreted as a prohibition.
2 If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined.

Silly question, but how do you "see" this inlining? How do you determine if your compiler has inlined something?

I believe it is by observing assembly output.

Originally Posted by cs32

Silly question, but how do you "see" this inlining? How do you determine if your compiler has inlined something?

I have been inspecting the generated code - mostly because I was trying to figure out which function was failing in Xen, and there isn't any simple way to debug kernel code - you have to rely on the crash-dump on the serial port and then backtrack what the address is. When you then look at the assembly code, you find that the function that the code is in isn't what you expected it to be [e.g. you have a function called "do_page_fault" that is called from "handle_intercept", but all the code in do_page_fault is actually inside handle_intercept - I found that quite annoying to be honest, because a 20 line C function is much easier to debug in assembler than a 20 line C function inlined into something that is already far too big (in C), and with all the other 20-line C functions that ALSO got inlined, it was HUGE].

I have probably spent far too much time inspecting compiler output.

--
Mats