220 32765 article Path: news.gmane.org!.POSTED!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Allow char pointers to traverse any part of a dynamic type Date: Tue, 13 Jun 2017 15:06:48 -0700 (PDT) Lines: 123 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2615_470638326.1497391608355" X-Trace: blaine.gmane.org 1497391610 21559 195.159.176.226 (13 Jun 2017 22:06:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Jun 2017 22:06:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKLT4PURQHRB6GDQHFAKGQEHVC75NI@isocpp.org Wed Jun 14 00:06:45 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKtxU-0005Dk-Vm for gclcip-std-proposals@m.gmane.org; Wed, 14 Jun 2017 00:06:45 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id v184sf67173019itc.15 for ; Tue, 13 Jun 2017 15:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=gbcK556llwHQl+eWhADh39MSiNmXZFovRGqF4Ky07hg=; b=xLP+T0xk7THrFlOuoIZjuw56d0YpI+5CqN+kAtu0jbo7emiQ4WpWpXvwfWHwkSC+3G awq/VXLLYi2vwEojkjGk2hd5PjyQbo094S8EdeIS3NbytvqwZC2oV4fYJ3Gk4WLvV+MO xPQN2oH8lYR03eBBPhKQWNSUZhVwhb2rW3mAUX1DieeqNviq4Ukw6qQiC6BkOBaCH7Qw UqK/93eoTKkPCyLC9eClKk3QTKxjPC/H0GX+gIH/t1WIHGjgaxlg8HtO/Z4nJeQvrMD4 F3vp2e/DeClYIghKS4cMbAfm2gtHU0QRxHxuJ5iyWOs73hLJ16Tlh5ibElOATQHjxDf9 XR9A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=gbcK556llwHQl+eWhADh39MSiNmXZFovRGqF4Ky07hg=; b=PZoCiYz4urNJs2qiGoQZcw6UKP4QkVOVVduQmMaH6tnf1zOqFJmRP8KxoB4M6pljny cDY9P0YwcCHLPOC2Hrnb6gdyPElHq9MlGp/29/mMe1XvVCQE46rA002zpp4NNscd96Dl KvtNYSO02x1QHmsC/FM13mdljuT206X9anZca2PqCm12wNyt0pQ94uV0wDLCUJmbQDVb BPtaekqLnrmUx919ARh6Nai7ipVCavItGTmI8cNxePNDcAvox1uaoAhxaGM3evsa6p/f Ocv4dfzv3oxQHjHMNkmseF9wA7UF6WCuEnrksIJwmLVmzWnia+sICGTyKaBzP+gF0KoE qpiw== 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: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=gbcK556llwHQl+eWhADh39MSiNmXZFovRGqF4Ky07hg=; b=SRU3d5pcwAJ0NWTo4uw5odf1KIbnZtI9pDd/8erCdn+qlL+2ymeUTfK0U1q6ZYx4pO v1zW/iZi9H3ZTniWPvj/1b+tJfLCJfZQGTPCLoKcxjq/WSEmBUa9DjFtA1ClqrvCuOAJ K1pBgDj34uzl2TTvvSC/4tis0QFUVlEX3T6UCneeXcAsSS0DVsFm7UEBZ/b2/vKVWbe0 hotkLS7nXjFPHOk0SoZ/+6wCmvHh1EjE9hLOyjAfA3OQFU3UyGOisr1ahvizeBuxzFUG 1q+uHFJktL7cDXkq17qlglPlImgwYmIleN/eyON7QhNblqrrQpVXqPegSQvtzSaEmBv8 kvVg== X-Gm-Message-State: AKS2vOzQyl0Gk9cwbrpIGnxptK6m+PyTu9MVwwz3DfDgD7YDnnQufV+V W1+p5Y4CtxD8Rz8w X-Received: by 10.36.38.14 with SMTP id v14mr7519436itv.6.1497391609706; Tue, 13 Jun 2017 15:06:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.25.8 with SMTP id j8ls221755ota.33.gmail; Tue, 13 Jun 2017 15:06:48 -0700 (PDT) X-Received: by 10.157.53.122 with SMTP id l55mr205689ote.17.1497391608836; Tue, 13 Jun 2017 15:06:48 -0700 (PDT) X-Original-Sender: myriachan@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:32765 Archived-At: ------=_Part_2615_470638326.1497391608355 Content-Type: multipart/alternative; boundary="----=_Part_2616_995862832.1497391608355" ------=_Part_2616_995862832.1497391608355 Content-Type: text/plain; charset="UTF-8" Currently, offsetof has limited use, because the only useful defined way to use the value returned by offsetof is to access members of a field in a char array after the class has been copied to it. My proposal is to allow char pointer arithmetic to traverse any part of the dynamic type of an object, rather than merely being limited to the subobject from which the pointer was originally derived. Such an adjusted char pointer would be allowed to cast back to non-char pointer type, then accessed, provided that all aliasing rules are followed. That is, if you cast back to non-char object pointer type and dereference, the type must more-or-less match the dynamic type of the object or subobject. (I suppose if you write rather than read, you might end up ending the lifetime of the object and reusing its storage, which would be legal, but not what you wanted.) struct Meow { int x; int y; }; int BadReadY(Meow *meow) { // This function has undefined behavior despite this being true. static_assert(offsetof(Meow, y) == offsetof(Meow, x) + sizeof(Meow::x)); int *p = &meow->x; return p[1]; } int GoodReadY(Meow *meow) { static_assert(offsetof(Meow, y) == offsetof(Meow, x) + sizeof(Meow::x)); char *p = reinterpret_cast(&meow->x); return *reinterpret_cast(p + sizeof(Meow::x)); } The reason for the change is to permit the following kind of code. Developers do this anyway already, despite having undefined behavior under the current Standard ([expr.add]/4). #define CONTAINING_RECORD(address, type, field) \ reinterpret_cast(reinterpret_cast(address) - offsetof(type, field)) Whether this would be legal for non-standard-layout types is a separate issue; see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0545r0.html Melissa -- 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/ed72f11f-3897-4bc8-b768-3c4ad3b2e174%40isocpp.org. ------=_Part_2616_995862832.1497391608355 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently, offsetof has limited use, because the only usef= ul defined way to use the value returned by offsetof is to access members o= f a field in a char array after the class has been copied to it.

My = proposal is to allow char pointer arithmetic to traverse any part of the dy= namic type of an object, rather than merely being limited to the subobject = from which the pointer was originally derived.=C2=A0 Such an adjusted char = pointer would be allowed to cast back to non-char pointer type, then access= ed, provided that all aliasing rules are followed.=C2=A0 That is, if you ca= st back to non-char object pointer type and dereference, the type must more= -or-less match the dynamic type of the object or subobject.=C2=A0 (I suppos= e if you write rather than read, you might end up ending the lifetime of th= e object and reusing its storage, which would be legal, but not what you wa= nted.)


struct Meow
{
=C2=A0=C2=A0=C2=A0 int x;
=C2=A0= =C2=A0=C2=A0 int y;
};

int BadReadY(Meow *meow)
{
=C2=A0=C2= =A0=C2=A0 // This function has undefined behavior despite this being true.<= br>=C2=A0=C2=A0=C2=A0 static_assert(offsetof(Meow, y) =3D=3D offsetof(Meow,= x) + sizeof(Meow::x));

=C2=A0=C2=A0=C2=A0 int *p =3D &meow->= x;
=C2=A0=C2=A0=C2=A0 return p[1];
}

int GoodReadY(Meow *meow)=
{
=C2=A0=C2=A0=C2=A0 static_assert(offsetof(Meow, y) =3D=3D offsetof= (Meow, x) + sizeof(Meow::x));

=C2=A0=C2=A0=C2=A0 char *p =3D reinter= pret_cast<char *>(&meow->x);
=C2=A0=C2=A0=C2=A0 return *rei= nterpret_cast<int *>(p + sizeof(Meow::x));
}


The reason= for the change is to permit the following kind of code.=C2=A0 Developers d= o this anyway already, despite having undefined behavior under the current = Standard ([expr.add]/4).

#define CONTAINING_RECORD(address, type, fi= eld) \
=C2=A0=C2=A0=C2=A0 reinterpret_cast<type *>(reinterpret_cas= t<char *>(address) - offsetof(type, field))


Whether this w= ould be legal for non-standard-layout types is a separate issue; see http:/= /www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0545r0.html

Melis= sa

--
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/ed72f11f-3897-4bc8-b768-3c4ad3b2e174= %40isocpp.org.
------=_Part_2616_995862832.1497391608355-- ------=_Part_2615_470638326.1497391608355-- .