220 30407 <9dd7067b-ec8d-463c-8971-ac49a320f68f@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Chris Hallock Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: P0298: A byte type definition: with undefined pointer arithmetic? Date: Sat, 7 Jan 2017 13:36:20 -0800 (PST) Lines: 70 Approved: news@gmane.org Message-ID: <9dd7067b-ec8d-463c-8971-ac49a320f68f@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2250_211835754.1483824980970" X-Trace: blaine.gmane.org 1483824985 8482 195.159.176.226 (7 Jan 2017 21:36:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2017 21:36:25 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCHINCHEQEFBBVN6YXBQKGQERAXNUSI@isocpp.org Sat Jan 07 22:36:19 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPyev-0001G3-UZ for gclcip-std-proposals@m.gmane.org; Sat, 07 Jan 2017 22:36:18 +0100 Original-Received: by mail-yw0-f200.google.com with SMTP id 206sf64546060ywb.2 for ; Sat, 07 Jan 2017 13:36:22 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HAn7a3Y8sOCB/Qx94EzoucqXuVJptf1jjp9q0pePyx4=; b=Jx89eGIftUNyCtdLCZ8hkf3CnRe7dFW7D7DxPT8tpsxZs+61xA6RXjBoQrg0YxuD6h 4cjm6EPgXBXTiSGG9aXriLvGiwW1rx7mnVeXTHvm7EIk16ANKwM/jALq2ScRj6vuhuYk DEd3jHWOfT8c4NZszvSbUiHFqQWvYv23QfHBvvn/EulvX6UocQPcuJZYCZ9qcTCjekPR sNoagk3mCnqAAdSCBpV9MNqnEsX7/QeUZHM/0lS0a1hHqfbMK0RwPU9/aPrYA0Tp2LwH I+nAiGNuCfYLMNt3kX3SrSyWN3MOwsJSV8AQcsto5Hz7bXANULBR5XQeL19BtIc6QOZo 20Kw== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HAn7a3Y8sOCB/Qx94EzoucqXuVJptf1jjp9q0pePyx4=; b=tcpjHDwcajUCwlm9Cwxl02g+lhkF9zYEobrMU3FHrsZX9muIBdE9gfClO8QDHP1bST lPzv9i8P1X1lZ2s7570GJdApOnB9EU/9jwgxZcyoDm9vlOqA17uajKXomsrkOJl7ayew Ygl1nlHGq3ZFJ9EPz8Au9d3bd6BZJpiMKggXZnIcnoOGE5sGUm6rQVFTXINT8Lu0hh/c L1c6cETCQJW+o0N/lR3RkCWp7KS+Q2WKFFsvWRAywD1YmMbXnJgVsjQM6r8BNNp7MzR4 jO0TcD93BBshoi6HrFvttnrsr7yd5WFlCPVEwNjFZHW/8/kBBIXWcCVSLQ3mlMo03ugG Mz0w== 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=HAn7a3Y8sOCB/Qx94EzoucqXuVJptf1jjp9q0pePyx4=; b=jjf21EiGrcqE0BOV/U21R/mOAHpZ135TJ/44cdTct7yl30sdVH0AULVyg2M6Qy+3HX 3sHrPrd+CJkOId+HH0WcJnG1R1G3aOkFBzq21dLonkEOMkLLvzT30ZONkCWUuZXwew6F lwcxUItCGUM4kX4yI140bnlTHyajmCHlLXY7YGUHHlTa6mbvKMuPRV9/vXVVuaAyEapR 59wEt0ccbvrFEEPpLWpSHxgtKjbY8wQdPUvLGE2hafUxLXK2OxwpWFbL9L6mNgSQORYB itHhKmZu/HEuHBlfA0D4LBYPNorJZdQyy+fYGsOHfgjgr0wJZ9BaieaNIcN6qcN3yGWo NykQ== X-Gm-Message-State: AIkVDXLprIRN5SG7jhLaJLz/o4LJl/yDsIJvel99XARkCW+kRBQxn7SCAdnMKWbJ3McJ4Q== X-Received: by 10.129.62.15 with SMTP id l15mr1884536ywa.67.1483824981969; Sat, 07 Jan 2017 13:36:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.115 with SMTP id p48ls3682146otd.19.gmail; Sat, 07 Jan 2017 13:36:21 -0800 (PST) X-Received: by 10.157.17.167 with SMTP id v36mr621589otf.12.1483824981320; Sat, 07 Jan 2017 13:36:21 -0800 (PST) In-Reply-To: X-Original-Sender: christopherhallock@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:30407 Archived-At: ------=_Part_2250_211835754.1483824980970 Content-Type: multipart/alternative; boundary="----=_Part_2251_1964019998.1483824980970" ------=_Part_2251_1964019998.1483824980970 Content-Type: text/plain; charset=UTF-8 On Saturday, January 7, 2017 at 12:07:59 PM UTC-8, D. B. wrote: > > That said, if you could elaborate on situations in which you think casting > to int, adding, then casting back formally improves things, then I'd be > interested. > Well, not realistic situations, no :). It's just a thought experiment. That is, there is no point in forbidding this kind of pointer arithmetic, *even if the Committee and compiler authors wanted to*, because you can acheive the same effect anyway with various, *well-formed* hacks, such as - performing the offset in the integer domain - performing the offset in non-C++ code (the ultimate fall-back!) - repeatedly incrementing the pointer by 1 and using std::launder on it, in a loop (Myriachan's idea in an old thread, IIRC) -- 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/9dd7067b-ec8d-463c-8971-ac49a320f68f%40isocpp.org. ------=_Part_2251_1964019998.1483824980970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, January 7, 2017 at 12:07:59 PM UTC-8, D. B. w= rote:
Tha= t said, if you could elaborate on situations in which you think casting to = int, adding, then casting back formally improves things, then I'd be in= terested.

Well, not realistic situatio= ns, no :). It's just a thought experiment. That is, there is no point i= n forbidding this kind of pointer arithmetic, even if the Committee and = compiler authors wanted to, because you can acheive the same effect any= way with various, well-formed hacks, such as
  • performing t= he offset in the integer domain
  • performing the offset in non-C+= + code (the ultimate fall-back!)
  • repeatedly incrementing the po= inter by 1 and using st= d::launder on it, in a loop (Myriachan's idea in an old thread, = IIRC)

--
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/9dd7067b-ec8d-463c-8971-ac49a320f68f= %40isocpp.org.
------=_Part_2251_1964019998.1483824980970-- ------=_Part_2250_211835754.1483824980970-- .