android_main vs main in the NDK

[Jim Graham]

Just curious.... I see a lot of "void android_main()" in NDK samples.
I know that's definitely not legal in standard C, but I don't whether
it's legal or not in C++.

Is this something that changed when C++ came along? Or is void strictly
for the Android NDK (i.e., still not legal in normal C++)? And what if
you're using C in the NDK? Is it then requied to return int, as is the
case in "normal" (i.e., not Android-NDK) C?

Thanks,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) | Tux (E Cat): DS B+Wd Y 6 Y L+++ W+ C++/C++ I+++
spook...@gmail.com | T++ A E H+ S V- F++ Q+++ P/P+ B++ PA+ PL SC---
< Running Mac OS X Lion > |
ICBM / Hurricane: | Tiggerbelle: DS W+S+Bts % 1.5 X L W C+++/C+
30.44406N 86.59909W | I+++ T A E++ H S++ V+++ Q+++ P B++ PA++ PL+ SC

Android Apps Listing at http://www.jstrack.org/barcodes.html

[Chris Stratton]

On Jun 23, 9:56 am, Jim Graham <spooky1...@gmail.com> wrote:
> Just curious....  I see a lot of "void android_main()" in NDK samples.
> I know that's definitely not legal in standard C

On the contrary, it's perfectly legal standard C. Try it with your
favorite non-android C compiler.

The key thing to remember is that you do not (in officially endorsed
usage) use the ndk to build a program, which is to say something that
should have a main() function called by the operating system.

Instead, you build a shared library, which is called from jni by the
java code. Somewhere, likely in the app_process startup tool that
initates zygote, there is a conventional main() function called by
linux in the course of creating the system-wide fork-parent of what
becomes your application's process. But since nothing in your
application is exec()'d, there's no need for a literal main() anywhere
in the code of an android app.

In previous versions of the ndk, you had to write your own java code,
and could define your functions to be any legal C construct (those
directly called by java have some constraints, but they can of course
call anything else). In more recent version of the ndk, the native
activity capability has been added where pre-written java and native
wrapper code is supplied to create an interface to native application
code. Part of that interface may be a requirement for an
android_main() function - and even though its name might have some
inspiration from the main() of a stand alone program, it is something
fundamentally different.

If you have some native application code determine the address of the
main() function of the process in which it is running, that will
probably fall within the range that /proc/pid##/maps gives for /system/
bin/app_process

[Dianne Hackborn]

You can use a different function name for your main entry point with this:  http://developer.android.com/reference/android/app/NativeActivity.html#META_DATA_FUNC_NAME 

Note that the default is ANativeActivity_onCreate; the android_main comes from the glue code you link into your app that implements ANativeActivity_onCreate, does some setup of the native environment it is providing, and then calls android_main.  This is fairly analogous to the startup code you would link into your own app that turns _main() or whatever the OS really calls to start the process into the main() method that is defined by C/C++.

We don't call this main() however because it is not semantically the same.  The android_main function is the entry point to an android runtime environment, with the expected message loops set up, etc.  And as Chris says, starting an NDK application is not a fork()/exec() like a traditional OS, it is a fork() of an already initialized Dalvik environment which then specializes itself for your app, has your NativeActivity started by the platform, and eventually loads and runs your native code.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Jim Graham]

On Sat, Jun 23, 2012 at 08:10:06AM -0700, Chris Stratton wrote:
> On Jun 23, 9:56?am, Jim Graham <spooky1...@gmail.com> wrote:
> > Just curious.... ?I see a lot of "void android_main()" in NDK samples.

> > I know that's definitely not legal in standard C
>
> On the contrary, it's perfectly legal standard C.

When did ANSI Standard C start accepting "void main()" ? Granted, it's
been a long time, but I definitely remember that, at least previously,
ANSI C did NOT allow main to be void, and doing so caused undefined
behavior.[1]

> Try it with your favorite non-android C compiler.

Usually, at least back then, compilers ignored it and, if anything,
issued a warning, but then when the program exited, it would still return
a (random) value or 255 (depending on the compiler, the phase of the
moon, the price of tea in China, or whatever else you want to blame it
on). But it ALWAYS returned something, even if you violated ANSI C and
declared main to be void.

I'd check in my book on ANSI C, but it's back from when main ALWAYS
returned an int, and void main was undefined, so it wouldn't indicate
when ANSI re-wrote the C standard.

I did just check, and yes, main still returns an int whether you want it
to or not. I also went ahead and did a quick test, where I declared main
as void. Here's the output:

(15:04) % gcc -Wall test.c -o test
test.c:3: warning: return type of 'main' is not 'int'
(15:05) % ./test
Hello World.zsh: exit 12 ./test
(15:05) %

As you can see, gcc still complains that main is not returning an int,
and when it exits, in this case, main returned 12 (i.e., an int).

Later,
--jim

[1] A common comment on comp.lang.c back then wss that undefined
behavior meant that the program could even cause monkeys to fly
out of your nose.....

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) | DMR: So fsck was originally called
spook...@gmail.com | something else.
< Running Mac OS X Lion > | Q: What was it called?
ICBM / Hurricane: | DMR: Well, the second letter was different.
30.44406N 86.59909W | -- Dennis M. Ritchie, Usenix, June 1998.

[Jim Graham]

On Sat, Jun 23, 2012 at 11:59:33AM -0700, Dianne Hackborn wrote:

[a great answer to my question, and why void android_main is ok,
even though void main() is undefined.]

Thanks, Dianne. :-)

Later,

--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) | Peter da Silva: No, try "rm -rf /"
spook...@gmail.com | Dave Aronson: As your life flashes before
< Running Mac OS X Lion > | your eyes, in the unit of time known as an
ICBM / Hurricane: | ohnosecond.... (alt.sysadmin.recovery)
30.44406N 86. 59909W |

[Chris Stratton]

On Jun 23, 4:11 pm, Jim Graham <spooky1...@gmail.com> wrote:
> On Sat, Jun 23, 2012 at 08:10:06AM -0700, Chris Stratton wrote:
> > On Jun 23, 9:56?am, Jim Graham <spooky1...@gmail.com> wrote:
> > > Just curious.... ?I see a lot of "void android_main()" in NDK samples.
> > > I know that's definitely not legal in standard C
>
> > On the contrary, it's perfectly legal standard C.
>
> When did ANSI Standard C start accepting "void main()" ?

It's not void main()

It's void android_main()

Two very different things - that's the whole point. Any C compiler
should quite happily accept the latter.

[Jim Graham]

On Sat, Jun 23, 2012 at 03:38:53PM -0700, Chris Stratton wrote:
> On Jun 23, 4:11?pm, Jim Graham <spooky1...@gmail.com> wrote:
> > On Sat, Jun 23, 2012 at 08:10:06AM -0700, Chris Stratton wrote:
> > > On Jun 23, 9:56?am, Jim Graham <spooky1...@gmail.com> wrote:
> > >

> > > > Just curious.... I see a lot of "void android_main()" in NDK samples.

> > > > I know that's definitely not legal in standard C
> >
> > > On the contrary, it's perfectly legal standard C.
> >
> > When did ANSI Standard C start accepting "void main()" ?
>
> It's not void main()
>
> It's void android_main()

> Two very different things - that's the whole point. Any C compiler
> should quite happily accept the latter.

As Dianne explained quite well. Yes, I know. But, look at my initial
post, where I was asking about THE DIFFERENCE, and said that I didn't
know about android_main, but knew that it (void main()) is NOT valid in
standard C. You then replied that void main() is perfectly legal in
standard C. So I was (prior to looking it up) curious as to when ANSI
changed the C standard (as you can easily read in my text which you
quoted).

After looking it up and, for grins, testing on a "non-Android C compiler"
(I didn't even know there WAS an Android C compiler---where is it on the
Market?) as you suggested, it was clear that void main() is still not
valid in standard C. That is NOT the same as the old K&R C from the
pre-ANSI C days, which I'm not sure about (nor do I care about it).

Is that more clear now? :-)

Later,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) | "> There it was, right in the title bar:
spook...@gmail.com | > Microsoft Operations POS."

< Running Mac OS X Lion > |

ICBM / Hurricane: | "Never before has a TLA been so appropriately
30.44406N 86.59909W | mis-parsed." (alt.sysadmin.recovery)

[Chris Stratton]

On Jun 23, 7:29 pm, Jim Graham <spooky1...@gmail.com> wrote:
> As Dianne explained quite well.  Yes, I know.  But, look at my initial
> post, where I was asking about THE DIFFERENCE, and said that I didn't
> know about android_main, but knew that it (void main()) is NOT valid in
> standard C.  You then replied that void main() is perfectly legal in
> standard C.

No, in fact I did not. Go back and read the first two messages in
this thread again as they don't say what you think they do.

I replied to your claim that void android_main() was not legal by
pointing out that it is actually perfectly legal.

The first occurrence of "void main()" in this thread is in your reply
to my reply.

> After looking it up and, for grins, testing on a "non-Android C compiler"
> (I didn't even know there WAS an Android C compiler---where is it on the
> Market?)

What would be the purpose of the android-ndk group if there was no C
compiler?

[Jim Graham]

On Sat, Jun 23, 2012 at 05:12:30PM -0700, Chris Stratton wrote:
> On Jun 23, 7:29?pm, Jim Graham <spooky1...@gmail.com> wrote:

> > But, look at my initial
> > post, where I was asking about THE DIFFERENCE, and said that I didn't
> > know about android_main, but knew that it (void main()) is NOT valid in
> > standard C.

> No, in fact I did not. Go back and read the first two messages in
> this thread again as they don't say what you think they do.

> I replied to your claim that void android_main() was not legal by
> pointing out that it is actually perfectly legal.

Ok, we have a simple misunderstanding here..... I said:

Just curious.... I see a lot of "void android_main()" in NDK

samples. I know that's definitely not legal in standard C,
but I don't whether it's legal or not in C++.

And then, when you said, "On the contrary, it's perfectly legal standard C."
I, having left out part of what I meant to type (that would be yet another
result of cancer #1), I assumed that you meant that void main was
perfectly legal in standard C, as I'd intended to mention that (and
thought that I had).

So there we have it. A simple misunderstanding, brought about by a
combination, in this case, of high-dose/long-duration of a really evil
chemo drug (for lots of things, but in this case, chemobrain), 3 brain
tumors, 3 brain surgeries to remove said tumors, and then whole-brain
max-dose radiation therapy, all back in 2006--2007. It happens, and
sometimes, I don't spot it (and that would be thanks to the 2.5 cm
diameter tumor that was in my left occipital lobe, which processes
visiual data from the optic nerve).

Later,
--jim

--
THE SCORE: ME: 2 CANCER: 0

73 DE N5IAL (/4) MiSTie #49997 < Running Mac OS X Lion >
spook...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W

"'Wrong' is one of those concepts that depends on witnesses."
--Catbert: Evil Director of Human Resources (Dilbert, 05Nov09)