220 24176 <1792754.26JppehsIG@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: Change the specified behavior when control flow reaches the end of non-void functions Date: Wed, 03 Feb 2016 13:51:18 -0800 Lines: 102 Approved: news@gmane.org Message-ID: <1792754.26JppehsIG@tjmaciei-mobl4> References: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> <3004028.jdIGuf4xbV@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1454536294 8550 80.91.229.3 (3 Feb 2016 21:51:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 21:51:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBWXMZG2QKGQEBXQCTJQ@isocpp.org Wed Feb 03 22:51:25 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aR5Ke-0006q1-9G for gclcip-std-proposals@m.gmane.org; Wed, 03 Feb 2016 22:51:24 +0100 Original-Received: by mail-wm0-f72.google.com with SMTP id l66sf33884201wml.1 for ; Wed, 03 Feb 2016 13:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=qRRPc7cmEHkD04H+DAfrtLtZgkC4ANb9zxLgRimkSRg=; b=oCWbmPTVvx1F1Z5KfKe00I9ca4YY/BsVHXjjDnMLiiwI7gnyITQSWhMHoRVMK8LfWU VGxMP5zTj0dUgNZ2q2632LyFFdnp8Rpu5IoaxMgAta+e+/ORIjFKGx/dzBKItUQczXiJ aysH6BDMNKlD746TL/jHz+FjBzU9fDBdPhwNGoQba6VisMLIqUbwVqtpFnwGeY7UspuA SbtkhUUmuqqv71tAFRmtJAXVMEurV0X+yOWPAWqTUTTFdPKomfD5XhZTx7Nlvh6UUlDF OndL6ba4TfBHA/doBbfDlUJUrMc8bo9d3hZyTLfGU/TZpPiq+ZUhVtJku7HnaGHXCYUt G/rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=qRRPc7cmEHkD04H+DAfrtLtZgkC4ANb9zxLgRimkSRg=; b=b4c+3mpWCajFdhL8XKFX13j/fBJDEI5dF3sidJ3XWiYrtzxHX40Hj2rwehzEkYT6Ll Odp+5Nis91Tr/fEMi0H0G2z46mcmSC+SZBCKjberxDm76WHXCnbjqxgSI28mi8CdSo6W JwMGprCTHBJpYpWcv8kDE5t4yhn5pvuC+z/lfKGYb91vRdC8+dYmq1KtnQ4xR3B5EVkJ PI7mTkMF4gnOO9E5rUopDwACtRkjjPfisyEmM9wbruPWIQAbQDqi11Wl9tfiHbCoclqj H4ZH9Y8CqQrahlg92KqSxQ6Gdol9r9OIx4Hawvz6bo06RLyipANCS7sr3QuXKG3snIvg yAFQ= X-Gm-Message-State: AG10YOTBtli8chs7Y0boRX7eF070w34yBcsCycsGK/fsHh2E7pDWMjcXjQTGFCA+sDnmBQ== X-Received: by 10.28.126.149 with SMTP id z143mr4042743wmc.4.1454536283721; Wed, 03 Feb 2016 13:51:23 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.153.20 with SMTP id b20ls28755wme.34.canary; Wed, 03 Feb 2016 13:51:21 -0800 (PST) X-Received: by 10.194.118.138 with SMTP id km10mr4653990wjb.57.1454536281508; Wed, 03 Feb 2016 13:51:21 -0800 (PST) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id h130si33414241wmh.13.2016.02.03.13.51.21 for ; Wed, 03 Feb 2016 13:51:21 -0800 (PST) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl4.localnet (jfdmzpr03-ext.jf.intel.com [134.134.139.72]) by gondolin.macieira.info (Postfix) with ESMTPSA id 8966E11AC24 for ; Wed, 3 Feb 2016 13:51:20 -0800 (PST) User-Agent: KMail/5.1.1 (Linux/4.3.3-6-default; KDE/5.18.0; x86_64; ; ) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24176 Archived-At: On quarta-feira, 3 de fevereiro de 2016 13:36:59 PST Matthew Woehlke wrote: > > There's a big difference with the two proposals. To make it ill-formed, > > you > > require the compiler to have absolutely no false positives or negatives. > > Calling std::terminate was also brought up in that thread. Also, those > issues can be addressed with standard 'not reachable' annotation, which > is valuable in its own right. That requires a modification of the source code. > > To make it call std::terminate(), we're only defining previously > > undefined behaviour and we don't need a 100% success rate. > > ...except now you're changing behavior if I *meant* to flow off the end > (e.g. because I'm doing something tricksy) to cause my program to fail > at runtime, rather than being able to detect at compile time that the > compiler wants to mangle my code. No, you never meant to fall off the edge because that's undefined behaviour. You may have been relying on it, which is a bug. Or you were in a "proprietary agreement" with your compiler by using some compiler switch. If you are, then your code is not portable anyway and there's nothing wrong with the compiler keeping the switch for a little longer, even though it violates the standard. > >> ...or you could just compile with -Werror=return-type. No diligence > >> required; your code won't build and you'll *have* to fix it. > > > > As Chris said in his OP, this does not catch everything due to false > > positives and false negatives. > > Do you actually have an example of a false positive? I've *never* seen > one, and I'm curious what such an example looks like... False positives are very easy. Just call a function that doesn't exit by returning and not mark with an unreachable annotation. Qt 4 example (because in Qt5, qFatal is Q_NORETURN -- except with MSVC): int f() { qFatal("Goodbye, cruel world!"); } This will most likely produce a warning, when the function does not return and therefore making it ill-formed would have made valid code fail to compile. False negatives are more difficult, but here's an example: enum E { V, V2 = 10 }; struct S { S(E); }; S f(E e) { switch (e) { case V: case V2: return e; } } The above triggers a warning with GCC and ICC, but not with Clang. > > The compiler is allowed to give up if it can't prove one way or the > > other, so it often opts for assuming you know what you've done. > > If the compiler can't prove an issue, does it still insert a > std::terminate? Why would it not also warn in such cases? I would > really, really hope that the compiler has a warning for any time it > inserts a std::terminate for this reason... but in that case, the value > of requiring it to insert the std::terminate becomes dubious. I would say yes, it can insert the std::terminate, but it need not warn if it can't be sure, because it can assume you meant to write it that way. See the cases above. The extra call to std::terminate is not a big deal: if your code is really bad and falls off the edge of the function, we now have a well- defined termination; if it was fine before and never reached that point, you've got a bit of dead code now. More importantly, making it ill-formed makes the situation worse, because you can ignore warnings, but you can't ignore a compilation error. > This approach (terminate at run-time rather than compile-time) feels > like a cop-out to me... and yes, "perfect is the enemy of good" and all > that, but here it feels too much like laziness. I'm not saying I agree with it. You're right, it is a cop-out: since we can't make it ill-formed, let's go for the next best thing. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/. .