[RFC] Deprecate "implicit int" for main() in C++

[RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

G++ allows the 'main' function to be declared without a return type:

$ gcc-8 -x c++ - <<< 'main() { }'
<stdin>:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type [-Wreturn-type]

We enabled -Wreturn-type by default in GCC 8, so code using the
extension will get warnings even without -Wall now. Users might want
to use -Werror=return-type to ensure they aren't bitten by the new
optimizations that assume control never reaches the end of a non-void
function.

Should we deprecate the "implicit int" extension for GCC 9?

Deprecating it wouldn't mean we have to remove it any time soon, and
it could still be allowed by -fpermissive.

N.B. we also allow "implicit int" in system headers, which we might
need to continue doing because some OS headers are not C++-aware, and
users can't fix their OS headers. That isn't true for 'main' because
users control that, and can fix it, and fixing it has no downside.

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 01:23 PM, Jonathan Wakely wrote:

> We enabled -Wreturn-type by default in GCC 8, so code using the
> extension will get warnings even without -Wall now. Users might want
> to use -Werror=return-type to ensure they aren't bitten by the new
> optimizations that assume control never reaches the end of a
> non-void function.

But ISO C++ allows control to reach the end of main(), and
automagically returns 0.  I guess you didn't mean that, but your reply
was confusing.

N4659, Section 6.6.1 Para 5:

 If control flows off the end of the compound-statement of main, the
 effect is equivalent to a return with operand 0 (see also 18.3).

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jason Merrill]

On Wed, Apr 25, 2018 at 9:53 AM, Andrew Haley <aph@redhat.com> wrote:
> On 04/25/2018 01:23 PM, Jonathan Wakely wrote:
>
>> We enabled -Wreturn-type by default in GCC 8, so code using the
>> extension will get warnings even without -Wall now. Users might want
>> to use -Werror=return-type to ensure they aren't bitten by the new
>> optimizations that assume control never reaches the end of a
>> non-void function.
>
> But ISO C++ allows control to reach the end of main(), and
> automagically returns 0.  I guess you didn't mean that, but your reply
> was confusing.
>
> N4659, Section 6.6.1 Para 5:
>
>  If control flows off the end of the compound-statement of main, the
>  effect is equivalent to a return with operand 0 (see also 18.3).

Indeed, so that optimization doesn't affect main, because there is no
undefined behavior.

The warning by default seems sufficient to me.

Jason

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 02:56 PM, Jason Merrill wrote:
> The warning by default seems sufficient to me.

Yes.  We've been bitten by this a few times, with mysterious crashes.
I'm not sure it even makes sense only to be a warning, but I guess
that's up to the C++ TC.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 14:59 +0100, Andrew Haley wrote:
>On 04/25/2018 02:56 PM, Jason Merrill wrote:
>> The warning by default seems sufficient to me.
>
>Yes.  We've been bitten by this a few times, with mysterious crashes.
>I'm not sure it even makes sense only to be a warning, but I guess
>that's up to the C++ TC.

It's not always possible for the compiler to prove that flowing off
the end never happens, even if the program state ensures that it can't
(e.g. by all callers enforcing the function's preconditions
correctly). So making it ill-formed is deemed too draconian whenever
this gets discussed.

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> On 25/04/18 14:59 +0100, Andrew Haley wrote:
>> On 04/25/2018 02:56 PM, Jason Merrill wrote:
>>> The warning by default seems sufficient to me.
>>
>> Yes.  We've been bitten by this a few times, with mysterious crashes.
>> I'm not sure it even makes sense only to be a warning, but I guess
>> that's up to the C++ TC.
> 
> It's not always possible for the compiler to prove that flowing off
> the end never happens, even if the program state ensures that it can't
> (e.g. by all callers enforcing the function's preconditions
> correctly). So making it ill-formed is deemed too draconian whenever
> this gets discussed.

Sure.  Having said that, the cases that bit me were those where control
always flowed off the end, i.e. the function contained no return statement.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 16:30 +0100, Andrew Haley wrote:
>On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
>> On 25/04/18 14:59 +0100, Andrew Haley wrote:
>>> On 04/25/2018 02:56 PM, Jason Merrill wrote:
>>>> The warning by default seems sufficient to me.
>>>
>>> Yes.  We've been bitten by this a few times, with mysterious crashes.
>>> I'm not sure it even makes sense only to be a warning, but I guess
>>> that's up to the C++ TC.
>>
>> It's not always possible for the compiler to prove that flowing off
>> the end never happens, even if the program state ensures that it can't
>> (e.g. by all callers enforcing the function's preconditions
>> correctly). So making it ill-formed is deemed too draconian whenever
>> this gets discussed.
>
>Sure.  Having said that, the cases that bit me were those where control
>always flowed off the end, i.e. the function contained no return statement.

I forget the "return *this;" in assignment operators embarrassingly
often. So often I've even contemplated a proposal to define flowing
off the end of an assignment operator equivalent to "return *this;"

Re: [RFC] Deprecate "implicit int" for main() in C++

[David Malcolm]

On Wed, 2018-04-25 at 16:54 +0100, Jonathan Wakely wrote:
> On 25/04/18 16:30 +0100, Andrew Haley wrote:
> > On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> > > On 25/04/18 14:59 +0100, Andrew Haley wrote:
> > > > On 04/25/2018 02:56 PM, Jason Merrill wrote:
> > > > > The warning by default seems sufficient to me.
> > > > 
> > > > Yes.  We've been bitten by this a few times, with mysterious
> > > > crashes.
> > > > I'm not sure it even makes sense only to be a warning, but I
> > > > guess
> > > > that's up to the C++ TC.
> > > 
> > > It's not always possible for the compiler to prove that flowing
> > > off
> > > the end never happens, even if the program state ensures that it
> > > can't
> > > (e.g. by all callers enforcing the function's preconditions
> > > correctly). So making it ill-formed is deemed too draconian
> > > whenever
> > > this gets discussed.
> > 
> > Sure.  Having said that, the cases that bit me were those where
> > control
> > always flowed off the end, i.e. the function contained no return
> > statement.
> 
> I forget the "return *this;" in assignment operators embarrassingly
> often. So often I've even contemplated a proposal to define flowing
> off the end of an assignment operator equivalent to "return *this;"

Could/should we offer a fix-it hint for such cases?

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 12:22 -0400, David Malcolm wrote:
>On Wed, 2018-04-25 at 16:54 +0100, Jonathan Wakely wrote:
>> On 25/04/18 16:30 +0100, Andrew Haley wrote:
>> > On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
>> > > On 25/04/18 14:59 +0100, Andrew Haley wrote:
>> > > > On 04/25/2018 02:56 PM, Jason Merrill wrote:
>> > > > > The warning by default seems sufficient to me.
>> > > >
>> > > > Yes.  We've been bitten by this a few times, with mysterious
>> > > > crashes.
>> > > > I'm not sure it even makes sense only to be a warning, but I
>> > > > guess
>> > > > that's up to the C++ TC.
>> > >
>> > > It's not always possible for the compiler to prove that flowing
>> > > off
>> > > the end never happens, even if the program state ensures that it
>> > > can't
>> > > (e.g. by all callers enforcing the function's preconditions
>> > > correctly). So making it ill-formed is deemed too draconian
>> > > whenever
>> > > this gets discussed.
>> >
>> > Sure.  Having said that, the cases that bit me were those where
>> > control
>> > always flowed off the end, i.e. the function contained no return
>> > statement.
>>
>> I forget the "return *this;" in assignment operators embarrassingly
>> often. So often I've even contemplated a proposal to define flowing
>> off the end of an assignment operator equivalent to "return *this;"
>
>Could/should we offer a fix-it hint for such cases?

Yes. For the general "missing return" that -Wreturn-type warns about
we can't know what a sensible return value would be. For assignment
operators 99.999% of them return *this and so a fix-it suggestion to
add exactly that would be good. This works:

@@ -15869,6 +15851,12 @@ finish_function (bool inline_p)
     {
       warning (OPT_Wreturn_type,
               "no return statement in function returning non-void");
+      if (DECL_NAME (fndecl) == assign_op_identifier)
+       {
+         rich_location richloc (line_table, input_location);
+         richloc.add_fixit_insert_before (input_location, "return *this;");
+         inform (&richloc, "Oi, Wakely, you forgot to return something");
+       }
       TREE_NO_WARNING (fndecl) = 1;
     }
 

But it should really check if *this is convertible to the return type,
just in case we have something unusual like:

struct X { int operator=(int) { } };

Re: [RFC] Deprecate "implicit int" for main() in C++

[Nathan Sidwell]

On 04/25/2018 12:45 PM, Jonathan Wakely wrote:

> @@ -15869,6 +15851,12 @@ finish_function (bool inline_p)
>      {
>        warning (OPT_Wreturn_type,
>                "no return statement in function returning non-void");
> +      if (DECL_NAME (fndecl) == assign_op_identifier)

IDENTIFIER_ASSIGN_OP_P (DECL_NAME (fndecl)), so += and friends are also 
caught?

nathan

-- 
Nathan Sidwell

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 13:13 -0400, Nathan Sidwell wrote:
>On 04/25/2018 12:45 PM, Jonathan Wakely wrote:
>
>>@@ -15869,6 +15851,12 @@ finish_function (bool inline_p)
>>     {
>>       warning (OPT_Wreturn_type,
>>               "no return statement in function returning non-void");
>>+      if (DECL_NAME (fndecl) == assign_op_identifier)
>
>IDENTIFIER_ASSIGN_OP_P (DECL_NAME (fndecl)), so += and friends are 
>also caught?

Thanks. I've included that in my patch and attached it to PR 85523.

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 14:53 +0100, Andrew Haley wrote:
>On 04/25/2018 01:23 PM, Jonathan Wakely wrote:
>
>> We enabled -Wreturn-type by default in GCC 8, so code using the
>> extension will get warnings even without -Wall now. Users might want
>> to use -Werror=return-type to ensure they aren't bitten by the new
>> optimizations that assume control never reaches the end of a
>> non-void function.
>
>But ISO C++ allows control to reach the end of main(), and
>automagically returns 0.  I guess you didn't mean that, but your reply
>was confusing.
>
>N4659, Section 6.6.1 Para 5:
>
> If control flows off the end of the compound-statement of main, the
> effect is equivalent to a return with operand 0 (see also 18.3).

Yes, I should have said "never reaches the end of a non-void function
other than main".

-Wreturn-type doesn't warn about flowing off the end of main, because
it's well-defined. There's definitely scope for confusion, because
-Wreturn-type gives the main function special treatment in two ways:

* Unlike normal functions, flowing off the end of main doesn't warn,
  because the standard defines what happens there.

* Unlike normal functions, G++ allows omitting the return type of
  main.
  This is a non-standard extension to C++ (implicit int return types
  are allowed by C89 but not by any version of C++).

What I'm proposing for deprecation is the non-standard extension that
allows:

main() { return 0; }

More concretely, deprecating it for a few releases would allow us to
apply the attached patch at some point in the future, so that instead
of:

rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type [-Wreturn-type]
 main() { return 0; }
      ^

We'd get:

rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type [-fpermissive]
 main() { return 0; }
      ^

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jason Merrill]

On Wed, Apr 25, 2018 at 10:40 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 25/04/18 14:53 +0100, Andrew Haley wrote:
>>
>> On 04/25/2018 01:23 PM, Jonathan Wakely wrote:
>>
>>> We enabled -Wreturn-type by default in GCC 8, so code using the
>>> extension will get warnings even without -Wall now. Users might want
>>> to use -Werror=return-type to ensure they aren't bitten by the new
>>> optimizations that assume control never reaches the end of a
>>> non-void function.
>>
>>
>> But ISO C++ allows control to reach the end of main(), and
>> automagically returns 0.  I guess you didn't mean that, but your reply
>> was confusing.
>>
>> N4659, Section 6.6.1 Para 5:
>>
>> If control flows off the end of the compound-statement of main, the
>> effect is equivalent to a return with operand 0 (see also 18.3).
>
>
> Yes, I should have said "never reaches the end of a non-void function
> other than main".
>
> -Wreturn-type doesn't warn about flowing off the end of main, because
> it's well-defined. There's definitely scope for confusion, because
> -Wreturn-type gives the main function special treatment in two ways:
>
> * Unlike normal functions, flowing off the end of main doesn't warn,
>  because the standard defines what happens there.
>
> * Unlike normal functions, G++ allows omitting the return type of
>  main.
>  This is a non-standard extension to C++ (implicit int return types
>  are allowed by C89 but not by any version of C++).
>
> What I'm proposing for deprecation is the non-standard extension that
> allows:
>
> main() { return 0; }
>
> More concretely, deprecating it for a few releases would allow us to
> apply the attached patch at some point in the future, so that instead
> of:
>
> rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type
> [-Wreturn-type]
> main() { return 0; }
>      ^
>
> We'd get:
>
> rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type
> [-fpermissive]
> main() { return 0; }
>      ^

I'm still not sure what the advantage is of changing the warning to an
error, but I suppose I wouldn't object either.

Jason

Re: [RFC] Deprecate "implicit int" for main() in C++

[Florian Weimer]

On 04/25/2018 04:40 PM, Jonathan Wakely wrote:
> More concretely, deprecating it for a few releases would allow us to
> apply the attached patch at some point in the future, so that instead
> of:
> 
> rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type 
> [-Wreturn-type]
> main() { return 0; }
>       ^
> 
> We'd get:
> 
> rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type 
> [-fpermissive]
> main() { return 0; }
>       ^

I wonder if it's currently a warning because the implicit int is used in 
configure checks.  If this is the case, maybe we cannot make it an error 
without altering the result of configure tests?

Thanks,
Florian

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 8 May 2018 at 12:35, Florian Weimer wrote:
> On 04/25/2018 04:40 PM, Jonathan Wakely wrote:
>>
>> More concretely, deprecating it for a few releases would allow us to
>> apply the attached patch at some point in the future, so that instead
>> of:
>>
>> rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type
>> [-Wreturn-type]
>> main() { return 0; }
>>       ^
>>
>> We'd get:
>>
>> rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type
>> [-fpermissive]
>> main() { return 0; }
>>       ^
>
>
> I wonder if it's currently a warning because the implicit int is used in
> configure checks.  If this is the case, maybe we cannot make it an error
> without altering the result of configure tests?

Sigh, you're probably right. Since GCC 8.1 any such configure tests
will get a warning (or an error with -Werror) so maybe they'll
eventually get fixed.

Jason already expressed a preference for not making the change anyway.

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andreas Schwab]

On Mai 08 2018, Florian Weimer <fweimer@redhat.com> wrote:

> I wonder if it's currently a warning because the implicit int is used in
> configure checks.

Is it?  At least in the GCC sources I couldn't find any occurence of
main without a preceding int.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."