public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Cc: arsen@aarsen.me, Jason Merrill <jason@redhat.com>
Subject: Handling of main() function for freestanding
Date: Wed, 28 Sep 2022 21:15:34 +0100	[thread overview]
Message-ID: <CAH6eHdRr2uYW=Q8BKvhx472LXkT+nCKQg4uYAETNCs+b=YY7GA@mail.gmail.com> (raw)

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 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

             reply	other threads:[~2022-09-28 20:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28 20:15 Jonathan Wakely [this message]
2022-09-29  6:00 ` Richard Biener
2022-09-29  7:12   ` Jakub Jelinek
2022-09-29  9:21     ` Jonathan Wakely
2022-10-04 22:25 ` Jason Merrill
2022-10-04 23:28   ` Joel Sherrill
2022-10-07 11:30   ` Jonathan Wakely
2022-10-07 13:51     ` Jason Merrill
2022-10-07 13:53       ` Jakub Jelinek
2022-10-13 17:03       ` Arsen Arsenović
2022-10-13 17:10         ` Jakub Jelinek
2022-10-13 17:26           ` Arsen Arsenović
2022-10-13 17:24         ` Jason Merrill
2022-10-13 20:14           ` Arsen Arsenović
2022-10-13 21:16             ` Jason Merrill
2022-10-14 10:04               ` Arsen Arsenović
2022-10-14 15:17                 ` Jason Merrill
2022-10-21 10:33                 ` Ping (c,c++): " Arsen Arsenović
2022-10-21 21:02                   ` Joseph Myers
2022-10-23 11:54                     ` Arsen Arsenović
2022-10-24 13:46                       ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6eHdRr2uYW=Q8BKvhx472LXkT+nCKQg4uYAETNCs+b=YY7GA@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=arsen@aarsen.me \
    --cc=gcc@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).