220 30376 <6a8ff667-3952-e6dd-a2cb-c0ba642b2ed1@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: Sat, 7 Jan 2017 21:52:22 +0900 Lines: 85 Approved: news@gmane.org Message-ID: <6a8ff667-3952-e6dd-a2cb-c0ba642b2ed1@f2.dion.ne.jp> 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 X-Trace: blaine.gmane.org 1483793566 24344 195.159.176.226 (7 Jan 2017 12:52:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2017 12:52:46 +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+bncBDIYVAE3UECRBE6JYPBQKGQEKXMIFYY@isocpp.org Sat Jan 07 13:52:41 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPqU4-0004jG-E2 for gclcip-std-proposals@m.gmane.org; Sat, 07 Jan 2017 13:52:32 +0100 Original-Received: by mail-qk0-f197.google.com with SMTP id c69sf80676930qkg.1 for ; Sat, 07 Jan 2017 04:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references: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=5OG8UkuAR0DOY/qYjIcfVh0eiMNpTQkiK16d+zjSwZU=; b=sLs5/0H4PlPlNdBvGqmE46C6vLvX+SlCQdO/ZLdGTC7vpc6FZ9k3ETMI5u/Ipo35+V wP/XtcAYCHM2wKAIJpfHyasARoOEBMkuy14YaHcOQztngIIPW/6mZWPmB9b2r6C9+hl5 /TW4E1TKOliFSnPBjAkFtCkXBsf7GG3EelvaFuPPxdqPxMD3tudrh3Z4GF9Gf82iJQKf lZ8A6CQ9tCY0SH7pvxQvVITq+WTUI65kWiBfIIFK6EFt52+Fv/GJW4q8U1DJKXorhFzk R6uWNVQ7S/k1iQxr1fuOnqOC1LUkP1ED+fyfGtrWkL5FTi1KjoGmrswO2/ofodPPBCnP AJbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references: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=5OG8UkuAR0DOY/qYjIcfVh0eiMNpTQkiK16d+zjSwZU=; b=qxDpTsotiUn47nkXq/D4Q+df39D7YV59LQ9GryB+4+Iee68GQ9PwqHaVNRDnoIqtnq rLXLyjmcjOilqQo74efw+oi2bi5T4avxwdgiZd+r6TzxPHMaRlX3e5VMFyUCOf8+eW2F qPSXOBCc2P/EgKmRrR9G/2nylrk+oCVI2EDobsIDP56yAuVEg6enk+/Pzkw9Bk2XJ7Ax Uuk1s2UPwp/Au9xqQYOIZ5HQpWNatxvKHxj8uqgAAVHCbVCb1JM8nC9TgwKSh0cSffWa DkdeX+xk8HCBnpif5B/3NRuEifrLe1NF+PNJ9xg1Invn7q3t98eyAZToL/QacKbLaQdG CglA== X-Gm-Message-State: AIkVDXJ6SFzJrzZeoFCfYbKarQ2TzAJK+IKBJ1+YEuikaBSATkXleeiT5AHEGRSkuIs+nA== X-Received: by 10.200.41.105 with SMTP id z38mr4409622qtz.78.1483793556611; Sat, 07 Jan 2017 04:52:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.33.148 with SMTP id e142ls1366990ita.1.gmail; Sat, 07 Jan 2017 04:52:35 -0800 (PST) X-Received: by 10.84.179.67 with SMTP id a61mr173642037plc.98.1483793555257; Sat, 07 Jan 2017 04:52:35 -0800 (PST) Original-Received: from dmta02.auone-net.jp (mail-ae0-f54.auone-net.jp. [106.187.230.54]) by mx.google.com with ESMTP id p5si82744118pgn.170.2017.01.07.04.52.34 for ; Sat, 07 Jan 2017 04:52:35 -0800 (PST) Received-SPF: pass (google.com: domain of k_satoda@f2.dion.ne.jp designates 106.187.230.54 as permitted sender) client-ip=106.187.230.54; Original-Received: from amlmta401.auone-net.jp (amlmta401-MM [10.188.23.180]) by dmta02.auone-net.jp (au one net mail) with ESMTP id D657740017F for ; Sat, 7 Jan 2017 21:52:33 +0900 (JST) Original-Received: from [0.0.0.0] ([209.222.77.220]) by amlmta401.auone-net.jp id 5870e48e000c7f2900004835000021061800058d4518; Sat, 07 Jan 2017 21:52:30 +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.54 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:30376 Archived-At: On 2017/01/07 8:27 +0900, Neil MacIntosh wrote: > I am still not sure you are correct about whether that access pattern is > actually undefined behavior. I'm afraid I'm not a language lawyer ;-) For me, it seems somewhat easy. Consider the following concrete example: int i = 0; unsigned char* p = reinterpret_cast(&i); p + 1; "p" points to "i", which is an object of type int. N4618 5.7 [expr.add] p6 says: > For addition or subtraction, if the expressions P or Q have type > "pointer to cv T", where T and the array element type are not similar > (4.5), the behavior is undefined. and footnote 86: > An object that is not an array element is considered to belong to a > single-element array for this purpose; see 5.3.1. "T" and "the array element type" in the above example are unsigned char and int, respectively. Then, because unsigned char and int are not similar, the behavior is undefined. Can you assert otherwise? > I would suggest you ask Core the question about undefined behavior via > their mailing reflector. Thank you. But I can't do that by myself now because I'm not a member of national body, and don't have attended a meeting. https://stackoverflow.com/questions/9070651/c-standards-committee-reflector-mailing-lists I'll seek someone who can forward this to the Core mailing reflector. (Do you know?) > I'm not sure how adding a new type that is distinct from existing > types used to also hold both integers and characters, but has the exact > same semantics as those types worsens the situation. It certainly does > nothing to encourage people to write the type of code we are discussing. If the proposal got adopted, someone will write an example code to demonstrate the new feature. But it will be hard to make such an example without violating the above explained language rule. > That sort of code is already written - millions of lines of it - and > more is written every day. Passing or blocking the byte proposal will > have no impact on that. The situation sounds same with singed integer overflow, or type based aliasing rule. People write that sort of code at their own risk, or with a guarantee given by the implementation. But it doesn't mean the committee can ignore the existing language rule to standardize a new feature. > I certainly 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. If something says "Here is the feature to do X, but X results in undefined behavior", I can't rely on that, can you? > The intent of the proposal is to enable people to be less ambiguous > about their intended use of a pointer (are they using it to access some > object storage, or an integer, or a character?). I think it is > relatively uncontroversial to say that having distinct types for these > different purposes makes programs easier to understand, analyze and > maintain. It sounds like that it is also good to add [[type-punned]] attribute for pointers without touching existing type based aliasing rule, or to add [[overflow-wraps]] attribute for signed integer types without touching existing rule on overflow. It might be actually good in some points you mentioned, but it adds the language another inconsistency which the standard should reduce/avoid. -- 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/6a8ff667-3952-e6dd-a2cb-c0ba642b2ed1%40f2.dion.ne.jp. .