220 35462 <5a8666ef-278e-4636-baaa-8f71c5a54a2d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: std::unreachable: the message parameter Date: Wed, 22 Nov 2017 20:10:05 -0800 (PST) Lines: 210 Approved: news@gmane.org Message-ID: <5a8666ef-278e-4636-baaa-8f71c5a54a2d@isocpp.org> References: <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_12319_1771334960.1511410205887" X-Trace: blaine.gmane.org 1511410209 7190 195.159.176.226 (23 Nov 2017 04:10:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Nov 2017 04:10:09 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIJ5FGZ2ACRUBFLYP5HK@isocpp.org Thu Nov 23 05:10:03 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHipt-0001Nx-7e for gclcip-std-proposals@m.gmane.org; Thu, 23 Nov 2017 05:10:01 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id g12sf8956020uaa.14 for ; Wed, 22 Nov 2017 20:10:08 -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: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; bh=l8sg5WR0mhMuSNDvcQPPH49HHYBeJFKR6jjcuEWC7OM=; b=GqpcNSZTDJFYoDf0OkK7jByDMwhkzeWsrrIKg+lsSKBjrekUK50thQ2KarXhnMunvu N8zUSDuyT1jVn+sz41f9F8rtzuhVv/mLFosiVLm6c7wM7lmZaaFZOJgBjduHbvgRHUJi vw7x4oe5SogNz5flzYMP/tzb9dbZti0UCmOFdPBlvQPq5cVINEdH1PaP7XTd2/ayr63m v9pHSpXecq2J9O+4efod/vZpvFHcOBj3IlPNJfFlMLU/64hGCmCqn2IhAPrSvwUjxl/3 l0EzOsGPcFD1ULJfnC7Z8a8XiDN9Ws1CKM+APW7gS3U4djB0Ffiq0bYodYAy9CL43Quj r4ig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=l8sg5WR0mhMuSNDvcQPPH49HHYBeJFKR6jjcuEWC7OM=; b=PDaOCXW/AZYRnxp0zDAmg/qrGYigpv8R4RcmcyWtzR9f7alugWHj+zj2QIbB6vBzhp 9X9EuqHQRXqENkqu8FJSVjNAQ/FRHPmTPBvRh8cMdjSakG9WcHRJXiijgt+NCAZsslwh 2qzDeVeVmqJFeNcIYPLX7zzPk48AwP9isnDkQjT5htWw+gPRf9sF4FqOBOkihqLEd44j D3EjGD+v5Q7zzR2n6cwuRgqdtiCIB0fmp5V7P3texija57xKY85+vExlVZJ/dAak6VNp 4GR4Yy6gjvdkevB9OtH84zGwrBSMwl0VlpWj0Q8vZA93OMoQyXVpZhAC3rVv3y3lwnXt zwiw== 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:in-reply-to:references :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=l8sg5WR0mhMuSNDvcQPPH49HHYBeJFKR6jjcuEWC7OM=; b=JcnxPM/+cHZyqWXFkHbsjjPAchLaoyHgdV/7jl+kn+RyD8OmEkQybcGy/RrNewjUFb 7XzAnSZoIZKR7YprE1dFCR5T9ujarPRLvKsvi0szoyyAYw9lhwol26gom/VkOyn+I95O Cv2uJxsyhkdRhIu9Cv4Cf49FCcbBGwTL3iIo+r3ODFeW5Jnp1uNLeZJ+ecluRGTlRtYL hvbouhC/DcPgjRA+olu8zfpuOv7HwIdGVhurLkEp85W9r54Dn1sInPeRRgOpYs09y1gz 6uz/wuMGDgqXA1yAo6beADtJZojrGU0W4pX7MbW5Fu0ognVcqJsZzwuG17xKO/biYShr Hkmg== X-Gm-Message-State: AJaThX6A8Jfp4OeYYn9+yLykl1gWCI9pftTKS/WdR94VAzC7EXdl29XJ fNpXgQwDYLzlhOEVe1TuMK45NA== X-Google-Smtp-Source: AGs4zMZstJ/JwGI4TTJB3h/TZfWF9UUrg4xmhi2GyPKykuX46QT5B3dtvhYWHyL/X64V87v/5gewcQ== X-Received: by 10.31.16.152 with SMTP id 24mr11083625vkq.6.1511410208226; Wed, 22 Nov 2017 20:10:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.141.197 with SMTP id p188ls1349467vkd.9.gmail; Wed, 22 Nov 2017 20:10:06 -0800 (PST) X-Received: by 10.31.159.211 with SMTP id i202mr2068011vke.3.1511410206417; Wed, 22 Nov 2017 20:10:06 -0800 (PST) In-Reply-To: <590f2abd-b676-4241-ae0d-1c7c95b8fe7d@isocpp.org> X-Original-Sender: arthur.j.odwyer@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:35462 Archived-At: ------=_Part_12319_1771334960.1511410205887 Content-Type: multipart/alternative; boundary="----=_Part_12320_1597834854.1511410205888" ------=_Part_12320_1597834854.1511410205888 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, November 22, 2017 at 11:06:23 AM UTC-8, Myriachan wrote: > > The consensus of the Toronto meeting's EWG was that std::unreachable,=20 > 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= =20 > that could be shown when an unreachable statement is executed in a debug= =20 > build. > > What I'm wondering is how unreachable should take that parameter. The=20 > obvious would be the following: > > [[noreturn]] void unreachable(const char *message); > Yes, that's correct. =20 > This would allow literal strings, but it would also allow constructions= =20 > 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",= =20 > i); > std::unreachable(message); > } > } > } > > Should such constructions be allowed, or should a literal string be=20 > required? If a literal string, how would that even be enforced, given th= at=20 > this is a library function? > I see no reason to require a literal string. The implementation of=20 std::unreachable(const char*) would look like this on GCC and Clang: [[noreturn]] void unreachable(const char *msg) { #ifdef DEBUG_MODE fprintf(stderr, "%s\n", msg); abort(); #else __builtin_unreachable(); #endif } Nothing here requires a literal string. In optimized builds in a mode in which the compiler does not output a=20 > diagnostic message, the call to std::snprintf could be elided by a smart= =20 > compiler; if the compiler knows that the only observable effect of=20 > std::snprintf is to modify "message", it could elide the call because=20 > std::unreachable is presumably implemented as an inline function. > Correct. In optimized builds, std::unreachable() had darn well BETTER be=20 equivalent to __builtin_unreachable(). In debug builds, a vendor might (unlikely IMO but possible) choose to print= =20 the given message and then abort. In that case, the call to std::snprintf= =20 could not be elided by the compiler, because its output was actually being= =20 used. I was considering wording such as the following, under the assumption that= =20 > a runtime value of "message" is allowed: > > "If an implementation issues a diagnostic upon the execution of=20 > std::unreachable(), and the 'message' parameter is present, the diagnosti= c=20 > message should include the characters of 'message' that are in the=20 > execution character set." > Assuming (correctly IMO) that the 'message' parameter is a `const char*`,= =20 it points to a null-terminated sequence of characters, which by definition= =20 are in the execution character set. The translation of a string literal (if= =20 any) from the source character set into a sequence of bytes in the=20 execution character set has, by runtime, already happened; and therefore=20 std::unreachable() doesn't need to do anything special to deal with it. =E2=80=93Arthur --=20 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 e= mail 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/5a8666ef-278e-4636-baaa-8f71c5a54a2d%40isocpp.or= g. ------=_Part_12320_1597834854.1511410205888 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, November 22, 2017 at 11:06:23 AM UTC-8, Myri= achan wrote:
T= he consensus of the Toronto meeting's EWG was that std::unreachable, in= tentionally causing undefined behavior, should have two forms:

[[nor= eturn]] void unreachable();
[[noreturn]] void unreachable($literal strin= g$);

The intent is similar to that of static_assert: have a diagnost= ic message that could be shown when an unreachable statement is executed in= a debug build.

What I'm wondering is how unreachable should tak= e that parameter.=C2=A0 The obvious would be the following:

[[noretu= rn]] void unreachable(const char *message);

=
Yes, that's correct.
=C2=A0
This would allow literal strin= gs, 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 so= mething();
=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 mes= sage[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), "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 such constructions be allo= wed, 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?

I see no reason to require a literal st= ring. The implementation of std::unreachable(const char*) would look like t= his on GCC and Clang:

[[noreturn]] void unreachabl= e(const char *msg) {
=C2=A0 =C2=A0 #ifdef DEBUG_MODE
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 fprintf(stderr, "%s\n", msg);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 abort();
=C2=A0 =C2=A0 #else
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __builtin_unreachable();
=C2=A0 = =C2=A0 #endif
}

Nothing here requires a = literal string.

In optimized builds in a mode in which the compiler = does not output a diagnostic message, the call to std::snprintf could be el= ided by a smart compiler; if the compiler knows that the only observable ef= fect of std::snprintf is to modify "message", it could elide the = call because std::unreachable is presumably implemented as an inline functi= on.

Correct. In optimized builds,= std::unreachable() had darn well BETTER be equivalent to __builtin_unreach= able().
In debug builds, a vendor might (unlikely IMO but possibl= e) choose to print the given message and then abort. In that case, the call= to std::snprintf could not be elided by the compiler, because its output w= as actually being used.

I was considering wording such as the follow= ing, under the assumption that a runtime value of "message" is al= lowed:

"If an implementation issues a diagnostic upon the execu= tion 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."
<= br>
Assuming (correctly IMO) that the 'message' parameter= is a `const char*`, it points to a null-terminated sequence of characters,= which by definition are in the execution character set. The translation of= a string literal (if any) from the source character set into a sequence of= bytes in the execution character set has, by runtime, already happened; an= d therefore std::unreachable() doesn't need to do anything special to d= eal with it.

=E2=80=93Arthur

--
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/5a8666ef-278e-4636-baaa-8f71c5a54a2d= %40isocpp.org.
------=_Part_12320_1597834854.1511410205888-- ------=_Part_12319_1771334960.1511410205887-- .