220 13344 article Path: news.gmane.org!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: proposal: deprecate failure to return (without annotation) Date: Mon, 29 Sep 2014 16:28:04 -0700 (PDT) Lines: 252 Approved: news@gmane.org Message-ID: References: <2106187.KAVOBzdsgo@tjmaciei-mobl4> <7890243.H6e3ul2NkU@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3920_1245532875.1412033284750" X-Trace: ger.gmane.org 1412033294 12582 80.91.229.3 (29 Sep 2014 23:28:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Sep 2014 23:28:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBBWWU6QQKGQEEXD4YBQ@isocpp.org Tue Sep 30 01:28:09 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XYkMS-00035f-Me for gclcip-std-proposals@m.gmane.org; Tue, 30 Sep 2014 01:28:09 +0200 Original-Received: by mail-pd0-f200.google.com with SMTP id p10sf47401990pdj.7 for ; Mon, 29 Sep 2014 16:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=SLYrQTIvbrCYnRf7KisDJuQwQybyCdmn/e+K3bMS75c=; b=MLk3csmCOEf0Oo4uIGhqXv/le6yyxqyjQM9iflr4b33OmkhVI1B/OnEeAHof2pxq4N 7SWHXaH33SD8qO7/hWaDXAwZtCMcEw/hyGrgs9joVk7tc5l5FTS4rT3TFNWfXaira366 EB+fmev8xgNCWETg20Mf44l1c8NWIMnRgTLjfSXcJW0NVqfWg4UoXzm2h5A6aOXlmC8G XR1B5sn9iTcXvwWQf70IrohamZpsz6wwhMYbqSnFjkI8q4OZfx+3Z8m+7X7g4pc20el4 7vTJqRUm/NJpndvF7SqAxVMVjbtB9//tVCdL5cu1viCy0OU6m4dQhs17ID4ldocNcpTS 4ZPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=SLYrQTIvbrCYnRf7KisDJuQwQybyCdmn/e+K3bMS75c=; b=bCOWXo4hgnIVYVIa0o/C3IMUXrWLBNwWrkZdW3WVwpBy+Oh9IQt4+VNH2ped3SMVdr h6d9wdnCDi27m+MnfeHKAev+DgmcQumxiSre16axJSXXEie49YJCGeynNzb7/QrBUWmt aL9kZcJXBswCc9UnwxzlI4QxRzkEKc6rQCXlw7zlBMYTDyT4Lh9hVJMeQ2e6oQ4m9kct PI7iVXxuLSH6h0kMNdZOH0rBR+F5flawyVUxKyB2StOWMeRGQ/n+0J23/+JE4e7IchUM Axl/DMvMSH1y8rlQyIkdsYNptuhsoIRu6OOPVGOCUKWK1u0KcdgeyCQvy50lBjyFxDTd hPtQ== X-Gm-Message-State: ALoCoQl4lHhHgdwFgwtZm1I6SFys6ZlNn7bArUlyHgDl05kzUfAKwc9j2W1SnY3yG6Y2ncTabHi7 X-Received: by 10.66.227.71 with SMTP id ry7mr34026104pac.13.1412033287421; Mon, 29 Sep 2014 16:28:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.138.199 with SMTP id qs7ls2464638igb.14.canary; Mon, 29 Sep 2014 16:28:06 -0700 (PDT) X-Received: by 10.51.17.104 with SMTP id gd8mr29549igd.7.1412033286666; Mon, 29 Sep 2014 16:28:06 -0700 (PDT) In-Reply-To: <7890243.H6e3ul2NkU@tjmaciei-mobl4> X-Original-Sender: gmisocpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:13344 Archived-At: ------=_Part_3920_1245532875.1412033284750 Content-Type: text/plain; charset=UTF-8 Hi Thiago On Tuesday, September 30, 2014 10:11:54 AM UTC+13, Thiago Macieira wrote: > > On Monday 29 September 2014 16:20:57 Matthew Woehlke wrote: > > > int foo(int x) > > > { > > > if (x == 1) > > > return doOne(); > > > else if (x == 2) > > > return doTwo(); > > > } > > > > Er... yes? "Yes!", even. That code, exactly as written, clearly has > > problems :-). I want the compiler to reject code like that. > > > > If there were an assert that (x == 1 || x == 2), then no. (Also a good > > reason to get the recent assert-related stuff sorted and into the > > standard :-).) > > > > IOW, if you want to write code like that, either tell the compiler > > explicitly to trust you to know what you're doing, or to trust that > > control can't fall off the end. (See also where I wrote about having a > > standardized way to say 'this is (we hope) unreachable'.) > > Oh, I definitely wouldn't write the code above as-is. I'd have written it > as: > > int foo(int x) noexcept > { > if (x == 1) > return doOne(); > else if (x == 2) > return doTwo(); > Q_UNREACHABLE(); > } > > Q_UNREACHABLE() expands to __builtin_unreachable() for GCC and Clang; > __assume(false) for ICC and MSVC. So that does what I wanted. > > Of course, it expands to absolutely nothing on other compilers (it > actually > expands to Q_ASSERT_X(false, "Q_UNREACHABLE was reached"), which in > release > mode expands to nothing). > > Note how the presence of the Q_UNREACHABLE() means I can't remove the "if > (x > == 2)" part of the conditional. > > If you want to make the code above ill-formed, please give me a > standardised > "this is unreachable" marker which is guaranteed to expand to zero code. > Don't > make me throw exceptions (my function is noexcept), and don't make me > place > calls to functions that don't need to be there. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > Would this construct serve your purpose: // Richards example with my additions: void app_exit() { exit(EXIT_FAILURE); } enum E { a, b, c }; int f(E e) { // switch cases must cover all enum values or trigger error/warning. switch (e) [[switch_on_all_enum_values]] (E) { case a: return 1; case b: return 2; case c: return 3; } noreturn { // Whatever happens in here, there must be no way out. app_exit(); } // noreturn works like this: // 1. Compiler attempts to verify the no_return block is unreachable, // if it unreachable, no code is generated and no warning is issued. // 2. If compiler can't verify the block is unreachable, a warning is issued // and the code inside the block is generated. // 3. If that code cannot be verified as not returning, // compiler injects code to ensure there is no way to return. // i.e. code to ensure std::terminate() is called the end of the block. try { app_exit(); } catch(...) { // Would be nice if compiler offered the ability to inject __debug_break here too in some situations like for debug builds. //.Then we can more easily diagnose the code where we made a wrong assumption. std::terminate(); } } Thoughts? -- --- 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 http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_3920_1245532875.1412033284750 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Thiago

On Tuesday, September 30, 2014 10:11:54 A= M UTC+13, Thiago Macieira wrote:
On Monday 29 S= eptember 2014 16:20:57 Matthew Woehlke wrote:
> > int foo(int x)
> > {
> >       if (x =3D=3D 1)
> >               return doOne= ();
> >       else if (x =3D=3D 2)
> >               return doTwo= ();
> > }
>=20
> Er... yes? "Yes!", even. That code, exactly as written, clearly ha= s
> problems :-). I want the compiler to reject code like that.
>=20
> If there were an assert that (x =3D=3D 1 || x =3D=3D 2), then no. = (Also a good
> reason to get the recent assert-related stuff sorted and into the
> standard :-).)
>=20
> IOW, if you want to write code like that, either tell the compiler
> explicitly to trust you to know what you're doing, or to trust tha= t
> control can't fall off the end. (See also where I wrote about havi= ng a
> standardized way to say 'this is (we hope) unreachable'.)

Oh, I definitely wouldn't write the code above as-is. I'd have written = it as:

int foo(int x) noexcept
{
        if (x =3D=3D 1)
                return doOne();
        else if (x =3D=3D 2)
                return doTwo();
        Q_UNREACHABLE();
}

Q_UNREACHABLE() expands to __builtin_unreachable() for GCC and Clang;= =20
__assume(false) for ICC and MSVC. So that does what I wanted.

Of course, it expands to absolutely nothing on other compilers (it actu= ally=20
expands to Q_ASSERT_X(false, "Q_UNREACHABLE was reached"), which in rel= ease=20
mode expands to nothing).

Note how the presence of the Q_UNREACHABLE() means I can't remove the "= if (x=20
=3D=3D 2)" part of the conditional.

If you want to make the code above ill-formed, please give me a standar= dised=20
"this is unreachable" marker which is guaranteed to expand to zero code= .. Don't=20
make me throw exceptions (my function is noexcept), and don't make me p= lace=20
calls to functions that don't need to be there.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4= 5358


Would this construct serve your purpos= e: 

// Richards example with my additions:

void app_exit()
{
    = exit(EXIT_FAILURE);
}

enum E { a, b, c };
int f(E= e) {
  // switch cases must cover all enum values or trigger error= /warning.
  switch (e) [[switch_on_all_enum_values]] (E) {
 = ; case a: return 1;
  case b: return 2;
  case c: return 3;=
  }
  noreturn { // Whatever happens in here, there= must be no way out.
      app_exit();
 = ; }

  // noreturn works like this:
  = // 1. Compiler attempts to verify the no_return block is unreachable,
&n= bsp; // if it unreachable, no code is generated and no warning is issued.  // 2. If compiler can't verify the block is unreachable, a wa= rning is issued
  // and the code inside the block is generated.  // 3. If that code cannot be verified as not returning,  // compiler injects code to ensure there is no way to return.=
  // i.e. code to ensure std::terminate() is called the en= d of the block.
  try
  {
     = app_exit();
  }
  catch(...)
  {
 =    // Would be nice if compiler offered the ability to = inject __debug_break here too in some situations like for debug b= uilds.
    //.Then we can more easily diagnos= e the code where we made a wrong assumption.
   = ; std::terminate();
  } 
}

Though= ts?

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_3920_1245532875.1412033284750-- .