Open mcandre opened 5 years ago
I agree with this. Just to give some background: when it was just C that we supported, I wanted to remove support for main()
entirely at some point. Unfortunately, there are an insane number of build systems out there that do compile-based checks that depend on main()
working. GNU Autoconf checks for the existence of a function by compiling something like this:
void function_you_are_looking_for();
void main() { function_you_are_looking_for(); }
I guess that for the existing toolchain setup that we have, we should keep main()
working, even if people shouldn't make use of it.
I am currently experimenting with building CloudABI software through Bazel. With Bazel it is far less common (or even impossible?) to do compile-based feature checking, meaning that the necessity for supporting main()
is likely a lot less. I could likely omit this source file entirely, meaning we simply get a hard linker error in case program_main()
is missing:
https://github.com/NuxiNL/cloudlibc/blob/master/src/libc/program/program_main.c
Porting applications from libc to cloudlibc is hard work, but one problem is particularly pernicious: cloudlibc toolchains do not warn the programmer when he or she forgets basic steps for correctly wiring up the new entrypoint.
<void|int> main([int argc[, char **argv]])
signature, as opposed to the recommendedvoid program_main(const argdata_t *ad)
signature.argdata::env::argdata()
.When this happens, the user observes the resulting CloudABI executable emit no output. It would be better for the runtime to present a dummy warning that the entrypoint was misconfigured. Best of all would be to detect this at compile time, and refuse to produce a binary with the wrong entrypoint.