Speaking from an RTEMS perspective, many of our examples show an
initialisation thread setting up arguments to invoke main() with argc and
argv and processing the return code.
I would lean to main(int, char**) being known special by gcc. It won't
bother the RTEMS embedded environment at all to do so. If it causes others
an issue, perhaps they need to align with standards a bit better. :)
--joel
On Tue, Oct 4, 2022, 5:26 PM Jason Merrill via Gcc <gcc@gcc.gnu.org> wrote:
> On 9/28/22 16:15, Jonathan Wakely wrote:
> > As part of implementing a C++23 proposal [1] to massively increase the
> > scope of the freestanding C++ standard library some questions came up
> > about the special handling of main() that happens for hosted
> > environments.
> >
> > As required by both C++ (all versions) and C (since C99), falling off
> > the end of the main() function is not undefined, the compiler is
> > required to insert an implicit 'return 0' [2][3]. However, this
> > special handling only applies to hosted environments. For freestanding
> > the return type or even the existence of main is
> > implementation-defined. As a result, GCC gives a -Wreturn-type warning
> > for this code with -ffreestanding, but not with -fhosted:
> >
> > int main() { }
> >
> > Arsen (CC'd) has been working on the libstdc++ changes for the
> > freestanding proposal, and several thousand libstdc++ tests were
> > failing when using -ffreestanding, because of the -Wreturn-type
> > warnings. He wrote a patch to the compiler [4] to add a new
> > -fspecial-main flag which defaults to on for -fhosted, but can be used
> > with -ffreestanding to do the implicit 'return 0' (and so disable the
> > -Wreturn-type warnings) for freestanding as well. This fixes the
> > libstdc++ test FAILs.
> >
> > However, after discussing this briefly with Jason it occurred to us
> > that if the user declares an 'int main()' function, it's a pretty big
> > hint that they do want main() to return an int. And so having
> > undefined behaviour do to a missing return isn't really doing anybody
> > any favours. If you're compiling for freestanding and you *don't* want
> > to return a value from main(), then just declare it as void main()
> > instead. So now we're wondering if we need -fspecial-main at all, or
> > if int main() and int main(int, char**) should always be "special",
> > even for freestanding. So Arsen wrote a patch to do that too [5].
> >
> > The argument against making 'int main()' imply 'special main' is that
> > in a freestanding environment, a function called 'int main()' might be
> > just a normal function, not the program's entry point. And in that
> > case, maybe you really do want -Wreturn-type warnings. I don't know
> > how realistic that is.
> >
> > So the question is, should Arsen continue with his -fspecial-main
> > patch, and propose it along with the libstdc++ changes, or should gcc
> > change to always make 'int main()' "special" even for freestanding?
> > void main() and long main() and other signatures would still be
> > allowed for freestanding, and would not have the implicit 'return 0'.
>
> I would rather not add a flag. No well-defined freestanding program is
> affected by implicit return 0 from main, it should always be enabled.
>
> > I have no horse in this race, so if the maintainers of bare metal
> > ports think int main() should not be special for -ffreestanding, so be
> > it. I hope the first patch to add -fspecial-main would be acceptable
> > in that case, and libstdc++ will use it when testing with
> > -ffreestanding.
> >
> > [1]
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1642r11.html
> > [2] https://eel.is/c++draft/basic.start.main#5.sentence-2
> > [3] https://cigix.me/c17#5.1.2.2.3.p1
> > [4]
> https://github.com/ArsenArsen/gcc/commit/7e67edaced33e31a0dd4db4b3dd404c4a8daba59
> > [5]
> https://github.com/ArsenArsen/gcc/commit/c9bf2f9ed6161a38238e9c7f340d2c3bb04fe443
> >
>
>
