Thread: void main question..

Originally Posted by cpjust

But on platforms where the return value of main() isn't used, why doesn't the compiler just allow you to use int main() but throw away the return value?

What do you mean?

I think what cpjust means is this:
On some embedded systems, main typically returns void because nothing is returned to the operating system. So why could the compiler not just accept int main and ignore whatever main returns?

A cookie to anyone who solves the problem!

In many embedded platforms, where the code starts to execute your code isn't necessarily called main() anyways...

And of course, there's nothing stopping some startup code that calls main from ignoring the return value. We do that all the time with functions like fread, fwrite, printf, sprintf, scanf, etc that are all returning an integer, but most applications do not use that return value.

--
Mats

Originally Posted by matsp

In many embedded platforms, where the code starts to execute your code isn't necessarily called main() anyways...

Precisely, on freestanding implementations the rules we often quote concerning main do not apply at all as it is all implementation defined.

Originally Posted by Elysia

I think what cpjust means is this:
On some embedded systems, main typically returns void because nothing is returned to the operating system. So why could the compiler not just accept int main and ignore whatever main returns?

A cookie to anyone who solves the problem!

If there is no name mangling, the support library that calls main won't know whether main returns a value or not.

Of course, on really tiny architectures, returning a value may not be done in a register. Say the system only really has ONE 8 bit general purpose register, so if you return a 16-bit integer value, it has to be passed like a struct is passed back on 32-bit compilers when you return a struct: The compiler provides space for the return value on the stack, and passes the address to that space to the as a hidden parameter to the function - in that case, it would take up extra code in both the startup code and the main function to provide the return value, and if it's completely ignored, the embedded user may not want to "spend" memory on returning a meaningless value.

But void main() is not exactly common.

In our embedded OS, "main" isn't called "main", but it still returns a value.

--
Mats

I think what cpjust means is this:
On some embedded systems, main typically returns void because nothing is returned to the operating system. So why could the compiler not just accept int main and ignore whatever main returns?

A cookie to anyone who solves the problem!

Originally Posted by Elysia

I think what cpjust means is this:
On some embedded systems, main typically returns void because nothing is returned to the operating system. So why could the compiler not just accept int main and ignore whatever main returns?

A cookie to anyone who solves the problem!

Deja vu?

Basically, on systems that only support void main(), they could see int main() and change it to void main() when you compile it. I don't deal with embedded devices, so I don't really care one way or another, but that would seem one way to make main() consistent across multiple platforms.

Originally Posted by Elysia

On some embedded systems, main typically returns void because nothing is returned to the operating system. So why could the compiler not just accept int main and ignore whatever main returns?

The answer then, is that it could.