220 30309 <21f7e054-6461-2687-8dba-3915a63a0873@f2.dion.ne.jp> article Path: news.gmane.org!.POSTED!not-for-mail From: Kazutoshi Satoda Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: P0298: A byte type definition: with undefined pointer arithmetic? Date: Fri, 6 Jan 2017 03:21:00 +0900 Lines: 50 Approved: news@gmane.org Message-ID: <21f7e054-6461-2687-8dba-3915a63a0873@f2.dion.ne.jp> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1483640486 25993 195.159.176.226 (5 Jan 2017 18:21:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2017 18:21:26 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 To: Neil MacIntosh , "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDIYVAE3UECRBIM5XLBQKGQEAKIO47Y@isocpp.org Thu Jan 05 19:21:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPCf9-0005tv-4T for gclcip-std-proposals@m.gmane.org; Thu, 05 Jan 2017 19:21:19 +0100 Original-Received: by mail-pf0-f199.google.com with SMTP id b22sf499257081pfd.0 for ; Thu, 05 Jan 2017 10:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to: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=8Dh2Dv+uzLPS5e6Q++ir0PiGQzWo+RrI8INCCTUcvME=; b=Aw7wwyvhXjPMTQuG035CK64c7040mzBBiwO5wfe7sW1lo4Asrzdm40HMhAH6Un01xb ZAt7hQwcBmlidH71zs45Og1PrXBA+4BSLeEdnhNHkYimQPAFbByrRlYUmXDQAHIuB9vY KnOtyPLr3GAw9VpQCpPl6CVZ+OfHm0kwaRz9vros2Ft7GC16JTkM1LSsbsltCcO7+cx8 rHbPJbLZ7q7A5N5bL+Kira0zWnxW+fLFl/s8LUKk/tq6u8LU6HsFilq5gJ7iUFH4++7v WmwvBJAz3lWbVQw7fXo8Bj9Z7lCtYuESMmZO/cNZrWS3rgyn9SYTVXYejbp0HRRqiRv2 1j+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to: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=8Dh2Dv+uzLPS5e6Q++ir0PiGQzWo+RrI8INCCTUcvME=; b=b6Gn3dskezhCxxHhp10Lia6sww0XxkOYzBXODSZS+aE67HBVS6oEsvMDMN09dV/6uT zv/JXDql8BouuXQsjOhm4R0GHlJjL9fdj/tsnHQ5nJe3LcKjG4fsofFZ6HgbsryI4Tkx U86/dQtwfdVZevbUco4ULB2StyfPlJLelGWpxt53c7qszTYjM5Al4EU3huM8y8Bl/cZM GKhAhPSf2FOdo8WNp/jzZz2D5TY4YSM+Pruc40JgkyuYxvyfxmMbOyeav32vHNFsqXYU x7mKz+pMyicTyc6ShSAkjSQLtO9vjHaziuHKa4G9I5/b+wpUDXwT1CzzbdpQWKka0MYZ Ls+g== X-Gm-Message-State: AIkVDXLceOEA+/uwNNbCD2UzexV+uW3i3X37e69WhKp01QSIB3a3YtKSb9gLen4fZqRwjQ== X-Received: by 10.99.0.86 with SMTP id 83mr36477768pga.67.1483640482641; Thu, 05 Jan 2017 10:21:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.175.216 with SMTP id p85ls7293798ioo.40.gmail; Thu, 05 Jan 2017 10:21:21 -0800 (PST) X-Received: by 10.84.138.165 with SMTP id 34mr159234658plp.20.1483640481285; Thu, 05 Jan 2017 10:21:21 -0800 (PST) Original-Received: from dmta02.auone-net.jp (mail-ae0-f55.auone-net.jp. [106.187.230.55]) by mx.google.com with ESMTP id j191si51857781pgd.157.2017.01.05.10.21.21 for ; Thu, 05 Jan 2017 10:21:21 -0800 (PST) Received-SPF: pass (google.com: domain of k_satoda@f2.dion.ne.jp designates 106.187.230.55 as permitted sender) client-ip=106.187.230.55; Original-Received: from amlmta048.auone-net.jp (amlmta048-MM [10.188.23.63]) by dmta02.auone-net.jp (au one net mail) with ESMTP id 37DE740008A for ; Fri, 6 Jan 2017 03:21:20 +0900 (JST) Original-Received: from [0.0.0.0] ([193.90.12.90]) by amlmta048.auone-net.jp id 586e8e9d0008465b0000137b000072a42000061c07ad; Fri, 06 Jan 2017 03:21:17 +0900 In-Reply-To: X-MXM-DELIVERY-TYPE: 3 X-Original-Sender: k_satoda@f2.dion.ne.jp X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of k_satoda@f2.dion.ne.jp designates 106.187.230.55 as permitted sender) smtp.mailfrom=k_satoda@f2.dion.ne.jp 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:30309 Archived-At: On 2017/01/05 4:21 +0900, Neil MacIntosh wrote: > There are plenty of examples of programs that perform byte-oriented > access in the domain of operating systems and communications protocols. > Consider reading or writing a wire-protocol, for example. In fact, you > seem to go on to give a brief sketch of exactly the sort of byte > 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 > pattern you described is undefined behavior, I'll just observe that the > Core Working Group reviewed the proposal (twice - once in Oulu, once in > Issaquah) and approved it for adoption. > > If you have specific questions about array-of-byte access to object > representations, then these questions would be completely orthogonal to > the std::byte proposal. They would exist today with unsigned char, and > they would continue to exist whether or not std::byte is adopted. So > modifying the proposal to address that issue is unnecessary. This > proposal is about creating a distinct type for accessing bytes of memory > - something that can also be done today using unsigned char or char. The > semantics of such access should not be changed by the proposal...it's a > different issue. Now I see your point of view. But I disagree. I think the defined-ness of byte-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 byte type which help such accesses is harmful by encouraging people to write programs with undefined behavior, and approving such a feature will decrease reliability of the standard and the committee. Such negative impact may outweigh the benefit of the feature. (I personally think "the benefit" of a new byte type, even when the said pointer 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 said problems. Please tell me if you (or someone) know a preferred way. -- k_satoda -- 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/21f7e054-6461-2687-8dba-3915a63a0873%40f2.dion.ne.jp. .