220 35453 <590f2abd-b676-4241-ae0d-1c7c95b8fe7d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: std::unreachable: the message parameter Date: Wed, 22 Nov 2017 11:06:23 -0800 (PST) Lines: 123 Approved: news@gmane.org Message-ID: <590f2abd-b676-4241-ae0d-1c7c95b8fe7d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_11274_455724614.1511377583455" X-Trace: blaine.gmane.org 1511377584 16028 195.159.176.226 (22 Nov 2017 19:06:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Nov 2017 19:06:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKLT4PURQHRBMEV27IAKGQELLBSHEI@isocpp.org Wed Nov 22 20:06:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHaLi-0003l6-CB for gclcip-std-proposals@m.gmane.org; Wed, 22 Nov 2017 20:06:18 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id k143sf9553061vke.23 for ; Wed, 22 Nov 2017 11:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=XKWr6b+t7XHoqn0HVjsGc2Pejx4l0RYPgmso1Pun9XU=; b=cTWOSQGNs1oODiMfOZ6K22n7V+JHbWv4hHdbH9bL3u/HGxbsRtQHQ3LuEpnfTV5IyY jVp1p1EoI47VOw7H1aLw0+iduhEOxwDeAHErEYIM21PFEGRhODr9hkf2EEcbqpKEIxow OCrUc2x/2IDCj8aEUVIxJz7PU+J6Jx8a7EwQGc56UPuZqsdpBIXtr8jlJcuTdtRUi1wm g0HJ6zpJWZmMKhAIpFbuHH0JNaD1rFjEMvLeoff/HEQU318hV1WmNOW8FXNYGuxJbrPP at1QJ6LfDLQ7pL+mKeo9E78Bo22gv4wFw4aloRn9YVUw0BDV7jBfiQtQMlWyI/N+iknU pqfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=XKWr6b+t7XHoqn0HVjsGc2Pejx4l0RYPgmso1Pun9XU=; b=bhEVfnVsXxsTkIkgcnuyeP/LvwUw54mkYjkPKOgZ6mx4l0ZrgOX9lE2B5TgxZ68jK4 xyugm9k7Og5bHdfEPgCNOaJ7Vd38Bl60SC/H0imZ+84UsrVDLXaOEatAAiTfkgTiELBP AoyKFFq6Gor6Bl6IU3aivvlLbyUteRDdmo3clRjdAjbNUBAnokNn04zjsLmi+yfC78aA V39P68rh3lrAYohyS1h5hC/qy0aor56IpBndAw3AuVfd81nSA7d/ILXyAmNQy6DkwRoc a/Kqdn2JZvXB0eJRvJj1VuBU24aeuI5biyk6wP0vyzuaOQG9nh22GryoEF6MgPXKZRpc XBvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=XKWr6b+t7XHoqn0HVjsGc2Pejx4l0RYPgmso1Pun9XU=; b=UPdY9X3EWNcf7QxoYlz+TJFtZRcjfHCK2WeRonHFPM4slFusuMRpDpGGpFQs4LcRb9 HEePnRBcCplMS/mNp8lhqsZixj8Axw+CfH8dyO3Kr8iKm4804R8LgTuwHtt3CKvMMuvv dU9C2rbYz8NYxMrWfiortLHpjml0fQFXgYo8guEf5WALdmM+SD9kyxDwfOG39wEf7EcY BZ4W1sNc/+n5xJ7DpWFzPWV+9RtfTJVJ21DNOuw77FnK972er4ijDOcvRV1azad9Jtin q29qAR9yJiBIhub59OoMjP7CrtP1uJqqUdgHoAKrSJH/xuXdSz2IRU7Yikc0wSJw+3QJ djrw== X-Gm-Message-State: AJaThX6KBrF25GImgC2whXlIBTuhT6KjYzLpo8eXjqaap97LkaxmU6+1 FjunVa+wdil6Ybj8rDycWABiVg== X-Google-Smtp-Source: AGs4zMYhGffbCyBEsChIv0yYtcLx6zOzSwKUVSPEVLfZ8Fxa3YEDbwwcZN9DTM7X9W6OHO/7xcIwpA== X-Received: by 10.31.169.129 with SMTP id s123mr9924480vke.73.1511377585651; Wed, 22 Nov 2017 11:06:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.65.35 with SMTP id j32ls1241681uad.8.gmail; Wed, 22 Nov 2017 11:06:24 -0800 (PST) X-Received: by 10.31.48.213 with SMTP id w204mr1949113vkw.12.1511377584036; Wed, 22 Nov 2017 11:06:24 -0800 (PST) X-Original-Sender: myriachan@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:35453 Archived-At: ------=_Part_11274_455724614.1511377583455 Content-Type: multipart/alternative; boundary="----=_Part_11275_1740156890.1511377583455" ------=_Part_11275_1740156890.1511377583455 Content-Type: text/plain; charset="UTF-8" The consensus of the Toronto meeting's EWG was that std::unreachable, intentionally causing undefined behavior, should have two forms: [[noreturn]] void unreachable(); [[noreturn]] void unreachable($literal string$); The intent is similar to that of static_assert: have a diagnostic message that could be shown when an unreachable statement is executed in a debug build. What I'm wondering is how unreachable should take that parameter. The obvious would be the following: [[noreturn]] void unreachable(const char *message); This would allow literal strings, but it would also allow constructions like the following: void f(int i) { switch (i) { case 0: case 2: something(); break; default: { char message[64]; std::snprintf(message, sizeof(message), "unknown value: %d", i); std::unreachable(message); } } } Should such constructions be allowed, or should a literal string be required? If a literal string, how would that even be enforced, given that this is a library function? In optimized builds in a mode in which the compiler does not output a diagnostic message, the call to std::snprintf could be elided by a smart compiler; if the compiler knows that the only observable effect of std::snprintf is to modify "message", it could elide the call because std::unreachable is presumably implemented as an inline function. I was considering wording such as the following, under the assumption that a runtime value of "message" is allowed: "If an implementation issues a diagnostic upon the execution of std::unreachable(), and the 'message' parameter is present, the diagnostic message should include the characters of 'message' that are in the execution character set." Melissa -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/590f2abd-b676-4241-ae0d-1c7c95b8fe7d%40isocpp.org. ------=_Part_11275_1740156890.1511377583455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The consensus of the Toronto meeting's EWG was that st= d::unreachable, intentionally causing undefined behavior, should have two f= orms:

[[noreturn]] void unreachable();
[[noreturn]] void unreacha= ble($literal string$);

The intent is similar to that of static_asser= t: have a diagnostic message that could be shown when an unreachable statem= ent is executed in a debug build.

What I'm wondering is how unre= achable should take that parameter.=C2=A0 The obvious would be the followin= g:

[[noreturn]] void unreachable(const char *message);

This w= ould allow literal strings, but it would also allow constructions like the = following:

void f(int i) {
=C2=A0=C2=A0=C2=A0 switch (i) {
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 case 2:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 something();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 default: {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 char message[64];
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::snprintf(message, sizeof(message), &quo= t;unknown value: %d", i);
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 std::unreachable(message);
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 }
}

Should su= ch constructions be allowed, or should a literal string be required?=C2=A0 = If a literal string, how would that even be enforced, given that this is a = library function?

In optimized builds in a mode in which the compile= r does not output a diagnostic message, the call to std::snprintf could be = elided by a smart compiler; if the compiler knows that the only observable = effect of std::snprintf is to modify "message", it could elide th= e call because std::unreachable is presumably implemented as an inline func= tion.

I was considering wording such as the following, under the ass= umption that a runtime value of "message" is allowed:

&quo= t;If an implementation issues a diagnostic upon the execution of std::unrea= chable(), and the 'message' parameter is present, the diagnostic me= ssage should include the characters of 'message' that are in the ex= ecution character set."

Melissa

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/590f2abd-b676-4241-ae0d-1c7c95b8fe7d= %40isocpp.org.
------=_Part_11275_1740156890.1511377583455-- ------=_Part_11274_455724614.1511377583455-- .