Please make such programs crash early and often. They are a nightmare to
maintain. Make them blow in the face of the original authors; not after
they are gone.
-- Gaby
On Thu, Aug 13, 2015 at 11:18 AM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Thu, Aug 13, 2015 at 1:52 AM, Sjoerd Meijer
> wrote:
>
>> Hi Richard,
>>
>> Thanks for reviewing. Agree, that was a bit confusing. More specifically,
>>
>> the warning message was confusing (i.e. wrong). This patch is for
>> compiling .c
>>
>> input in C++ mode. The new flag should be ignored for C++ **input**, and
>> indeed
>>
>> not when it is in C++ *mode* as the warning message said earlier. So I
>> have
>>
>> changed the warning message accordingly and hope that solves it, see
>> attached
>>
>> patch.
>>
>
> What is the distinction you're trying to draw here? This patch still
> doesn't make sense to me. This flag is only meaningful when compiling as
> C++. You ignore it when compiling as C but produce a warning that says it's
> ignored when compiling as C++.
>
>
>> Cheers.
>>
>>
>>
>> *From:* meta...@gmail.com [mailto:meta...@gmail.com] *On Behalf Of *Richard
>> Smith
>> *Sent:* 12 August 2015 23:06
>> *To:* Sjoerd Meijer
>> *Cc:* Hal Finkel; Marshall Clow; cfe-commits
>>
>> *Subject:* Re: [PATCH] RE: [cfe-dev] missing return statement for
>> non-void functions in C++
>>
>>
>>
>> This patch seems a bit confused. You warn that the flag is ignored in
>> C++, but it only has an effect in C++. You have a testcase with a .c
>> extension that is built with -x c++.
>>
>>
>>
>> On Wed, Aug 12, 2015 at 5:23 AM, Sjoerd Meijer
>> wrote:
>>
>> [ + cfe-commits@lists.llvm.org ]
>>
>>
>>
>> Hi,
>>
>> The functionality is now available under a flag, see attached patch. Note
>> that the flag is ignored in C++ mode, so it will help the use case of
>> compiling (legacy) C code with a C++ compiler.
>>
>> Cheers,
>>
>> Sjoerd.
>>
>>
>>
>> *From:* Sjoerd Meijer [mailto:sjoerd.mei...@arm.com
>> ]
>> *Sent:* 03 August 2015 11:40
>> *To:* 'Richard Smith'
>> *Cc:* Hal Finkel; Marshall Clow; cfe-...@cs.uiuc.edu Developers; cfe
>> commits
>> *Subject:* RE: [PATCH] RE: [cfe-dev] missing return statement for
>> non-void functions in C++
>>
>>
>>
>> Hi Richard,
>>
>>
>>
>> I agree with your conclusions and will start preparing a patch for option
>> 3) under a flag that is off by default; this enables folks to build/run C
>> code in C++. I actually think option 2) would be a good one too, but as it
>> is already available under a flag I also don’t see how useful it is
>> combining options 2) and 3) with another (or one more) flag that is off by
>> default.
>>
>>
>>
>> Cheers.
>>
>>
>>
>> *From:* meta...@gmail.com [mailto:meta...@gmail.com ] *On
>> Behalf Of *Richard Smith
>> *Sent:* 31 July 2015 19:46
>> *To:* Sjoerd Meijer
>> *Cc:* Hal Finkel; Marshall Clow; cfe-...@cs.uiuc.edu Developers; cfe
>> commits
>> *Subject:* Re: [PATCH] RE: [cfe-dev] missing return statement for
>> non-void functions in C++
>>
>>
>>
>> On Fri, Jul 31, 2015 at 7:35 AM, Sjoerd Meijer
>> wrote:
>>
>> Hi, I am not sure if we came to a conclusion. Please find attached a
>> patch. It simply removes the two lines that insert an unreachable statement
>> (which cause removal of the return statement). Please note that at -O0 the
>> trap instruction is still generated. Is this something we could live with?
>>
>>
>>
>> I don't think this is an improvement:
>>
>>
>>
>> This doesn't satisfy the folks who want an 'unreachable' for better code
>> size and optimization, and it doesn't satisfy the folks who want a
>> guaranteed trap for security, and it doesn't satisfy the folks who want
>> their broken code to limp along (because it'll still trap at -O0), and it
>> is at best a minor improvement for the folks who want missing returns to be
>> more easily debuggable (with -On, the code goes wrong in the caller, or
>> appears to work, rather than falling into an unrelated function, and
>> debugging this with -O0 was already easy).
>>
>>
>>
>> I think there are three options that are defensible here:
>>
>> 1) The status quo: this is UB and we treat it as such and optimize on
>> that basis, but provide a trap as a convenience at -O0
>>
>> 2) The secure approach: this is UB but we always trap
>>
>> 3) Define the behavior to return 'undef' for C types: this allows
>> questionable C code that has UB in C++ to keep working when built with a
>> C++ compiler
>>
>>
>>
>> Note that (3) can be combined with either (1) or (2). (2) is already
>> available via the 'return' sanitizer. So this really reduces to: in those
>> cases where C says it's OK so long as the caller doesn't look at the
>> returned value (and where the return type doesn't have a non-trivial copy
>> constructor or destructor, isn't a reference, and so on), should we attempt
>> to preserve the C behaviour? I would be OK with putting that behind a `-f`
>> flag (perhaps `-fstrict-return` or similar) to support those folks who want
>> to build C
