220 30366 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Neil MacIntosh' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: RE: P0298: A byte type definition: with undefined pointer arithmetic? Date: Fri, 6 Jan 2017 23:27:10 +0000 Lines: 86 Approved: news@gmane.org Message-ID: References: <21f7e054-6461-2687-8dba-3915a63a0873@f2.dion.ne.jp> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1483745238 26664 195.159.176.226 (6 Jan 2017 23:27:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2017 23:27:18 +0000 (UTC) To: Kazutoshi Satoda , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCT4NWETZQJBBUGPYDBQKGQEGB36DMA@isocpp.org Sat Jan 07 00:27:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPduf-0005x5-ER for gclcip-std-proposals@m.gmane.org; Sat, 07 Jan 2017 00:27:09 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id 128sf774624294oig.4 for ; Fri, 06 Jan 2017 15:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :spamdiagnosticoutput:spamdiagnosticmetadata :content-transfer-encoding:mime-version: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=7Jpldnw/U1QS4Sd6iNwQpvdATSnDc8Ai2dfcsrNQz2M=; b=ZQqMi//VqCfZyPcwl50M0R59xEOmXlHseYCxDUMxlyIVwWzI5AkvqSpiEr1kBAFjjt IyXyoE1ypWHQ99QrMWKlvmtI0xmiUws7odae9Gd3Luc8VfgtNoWBH0g4NNCxb6KN7BGk 3QLstdnuB8aZj1qmMpMJMlb4i/x8XfwPPNxkRMa1ppcl2A/UeR02JBuYRCsHcwOEKZK4 i6vj7vCI5S6cMP+AvvfAwigk1GFiX+LIGXypprzk X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :spamdiagnosticoutput:spamdiagnosticmetadata :content-transfer-encoding:mime-version: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=7Jpldnw/U1QS4Sd6iNwQpvdATSnDc8Ai2dfcsrNQz2M=; b=VlaYJA8C5zZO8qqPQ2hfen2KStVuPPzJ8S0vFI5l1HtJ+q41UhTtp5zfEAYsFt6akv cJ/LeA+hE2Ou0AQtl6J1MIJGckwFpdCUnsw1I+IFiN53+3CmrUdo8e2OiYFjm1ZWRdNw VXTjHZK6jlDmgQvmM0iWAMKoAp819HgDk+BhhKFCvQRK4vC+qGkyP1i2gd0d5M9+HIgF j3TXRGULov4d4MspDsLdfshyvApyAQWCS2XB X-Gm-Message-State: AIkVDXIEalaExJtdzU98lY5J2ywb+di/F1go5VT2l1vpWlcJQ+AooRvTgsE+uYGh13ufig== X-Received: by 10.157.48.70 with SMTP id w6mr1420958otd.31.1483745233092; Fri, 06 Jan 2017 15:27:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.46.77 with SMTP id c13ls2653593otd.49.gmail; Fri, 06 Jan 2017 15:27:12 -0800 (PST) X-Received: by 10.157.42.19 with SMTP id t19mr2105418ota.257.1483745232408; Fri, 06 Jan 2017 15:27:12 -0800 (PST) Original-Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on071b.outbound.protection.outlook.com. [2a01:111:f400:fe42::71b]) by mx.google.com with ESMTPS id 5si34927486otc.91.2017.01.06.15.27.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Jan 2017 15:27:12 -0800 (PST) Received-SPF: pass (google.com: domain of neil.macintosh@microsoft.com designates 2a01:111:f400:fe42::71b as permitted sender) client-ip=2a01:111:f400:fe42::71b; Original-Received: from DM5PR03MB2825.namprd03.prod.outlook.com (10.175.105.11) by DM5PR03MB2826.namprd03.prod.outlook.com (10.175.105.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Fri, 6 Jan 2017 23:27:10 +0000 Original-Received: from DM5PR03MB2825.namprd03.prod.outlook.com ([10.175.105.11]) by DM5PR03MB2825.namprd03.prod.outlook.com ([10.175.105.11]) with mapi id 15.01.0829.007; Fri, 6 Jan 2017 23:27:10 +0000 Thread-Topic: P0298: A byte type definition: with undefined pointer arithmetic? Thread-Index: AQHSZndgl96bd9O4NEuh6V6iYPQ+OaEosBhggAGD5wCAAA/qMA== In-Reply-To: <21f7e054-6461-2687-8dba-3915a63a0873@f2.dion.ne.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.251.73] x-ms-office365-filtering-correlation-id: 21372773-cb7a-4773-ada0-08d4368b899b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR03MB2826; x-microsoft-exchange-diagnostics: 1;DM5PR03MB2826;7:XC53cOl+P3YyKi/2oYwjKnICn6kqjD5AEaiFhOwO39ZdKFPh49a2vn9+c1E7wPjDGACEFiKHERVtBAPIXg+GoRr4l2LXgca1AfJiT8oPxsAxFA8dpC5K875QBHxKU1Opuq3OetFBmQJCELBntzuaqxUKZxBITDMg7ZfmDSYm6y146xr8QWMGmCtnS3za8452qlAlpB/xsNXspNUc+nlP/sYyldwHfhrE83I2KWhwUCv1R+xZjtSD+grkKpaStfNuPPektLrzTW7DnqjQEuu4WNFmAzLlgprO9uZDtbFuSpo1gScd3BpA4QV3ey05TmiU6XVfohCV6OiO92WVOSUoSlzDdza4Z/kwKsZCvYWHVRftHj/skIgsLTs1AiqJwJunSnYPPEmhnqHZ9kTgkIUW23XMOUPubssgCrJHgGVWW6P4FLnoGd/0wEAUSCfxzSBeK7sPoEDAmoW2nZwg1ThJM+8jCXAOEftf+SMDFe/f9Sk= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6047074)(6072148);SRVR:DM5PR03MB2826;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2826; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(24454002)(13464003)(377454003)(189002)(199003)(50986999)(3660700001)(7696004)(25786008)(6506006)(10090500001)(561944003)(77096006)(5660300001)(229853002)(33656002)(38730400001)(55016002)(99286003)(54356999)(189998001)(76176999)(2501003)(74316002)(9686003)(6436002)(305945005)(122556002)(3280700002)(66066001)(81166006)(68736007)(7736002)(8676002)(81156014)(102836003)(2906002)(2950100002)(6116002)(107886002)(8936002)(3846002)(5005710100001)(86612001)(105586002)(106356001)(101416001)(5001770100001)(106116001)(92566002)(2900100001)(8990500004)(10290500002)(86362001)(97736004);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR03MB2826;H:DM5PR03MB2825.namprd03.prod.outlook.com;FP R:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 23:27:10.0946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2826 X-Original-Sender: neil.macintosh@microsoft.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@microsoft.com; spf=pass (google.com: domain of neil.macintosh@microsoft.com designates 2a01:111:f400:fe42::71b as permitted sender) smtp.mailfrom=Neil.MacIntosh@microsoft.com; dmarc=pass (p=QUARANTINE dis=NONE) header.from=microsoft.com X-Original-From: Neil MacIntosh 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:30366 Archived-At: I am still not sure you are correct about whether that access pattern is ac= tually undefined behavior. I'm afraid I'm not a language lawyer ;-) I would suggest you ask Core the question about undefined behavior via thei= r mailing reflector. I'm not sure how adding a new type that is distinct from existing types use= d to also hold both integers and characters, but has the exact same semanti= cs as those types worsens the situation. It certainly does nothing to encou= rage people to write the type of code we are discussing. That sort of code = is already written - millions of lines of it - and more is written every da= y. Passing or blocking the byte proposal will have no impact on that. I cer= tainly don't see what sort of evidence you can point to that adding "byte" = in addition to "unsigned char", would somehow reduce the reliability of the= language. The intent of the proposal is to enable people to be less ambiguous about t= heir intended use of a pointer (are they using it to access some object sto= rage, or an integer, or a character?). I think it is relatively uncontrover= sial to say that having distinct types for these different purposes makes p= rograms easier to understand, analyze and maintain.=20 Neil. -----Original Message----- From: Kazutoshi Satoda [mailto:k_satoda@f2.dion.ne.jp]=20 Sent: Thursday, January 5, 2017 10:21 AM To: Neil MacIntosh ; std-proposals@isocpp.org Subject: Re: P0298: A byte type definition: with undefined pointer arithmet= ic? On 2017/01/05 4:21 +0900, Neil MacIntosh wrote: > There are plenty of examples of programs that perform byte-oriented=20 > access in the domain of operating systems and communications protocols. > Consider reading or writing a wire-protocol, for example. In fact, you=20 > seem to go on to give a brief sketch of exactly the sort of byte=20 > oriented access people want to perform. It sounds like that what I suspected is going on. Hmm. > Rather than speculate on core wording myself, and whether or not the=20 > pattern you described is undefined behavior, I'll just observe that=20 > the Core Working Group reviewed the proposal (twice - once in Oulu,=20 > once in > Issaquah) and approved it for adoption. > > If you have specific questions about array-of-byte access to object=20 > representations, then these questions would be completely orthogonal=20 > to the std::byte proposal. They would exist today with unsigned char,=20 > and they would continue to exist whether or not std::byte is adopted.=20 > So modifying the proposal to address that issue is unnecessary. This=20 > proposal is about creating a distinct type for accessing bytes of=20 > memory > - something that can also be done today using unsigned char or char.=20 > The semantics of such access should not be changed by the=20 > proposal...it's a different issue. Now I see your point of view. But I disagree. I think the defined-ness of b= yte-oriented access is not orthogonal to the proposal, rather I see it as a= major factor of the impact of the proposal. If the byte-oriented access results in undefined behavior, adding a new byt= e type which help such accesses is harmful by encouraging people to write p= rograms with undefined behavior, and approving such a feature will decrease= reliability of the standard and the committee. Such negative impact may ou= tweigh the benefit of the feature. (I personally think "the benefit" of a new byte type, even when the said po= inter arithmetic were defined, is not so significant; I can live without it= ..) I'll seek a way to ask CWG whether the approval is stable in sight of the s= aid problems. Please tell me if you (or someone) know a preferred way. -- k_satoda --=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/DM5PR03MB28250208BA0FC6A7AF60F80989630%40DM5PR03= MB2825.namprd03.prod.outlook.com. .