220 24944 <29412bcf-9f0b-4c1e-9ffb-b67943e2dfd1@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: standard attribute for unions to pun types? Date: Fri, 4 Mar 2016 17:21:15 -0800 (PST) Lines: 144 Approved: news@gmane.org Message-ID: <29412bcf-9f0b-4c1e-9ffb-b67943e2dfd1@isocpp.org> References: <68af543f-b30b-447b-8709-56ccd847735a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1474_1858167902.1457140875329" X-Trace: ger.gmane.org 1457140879 15493 80.91.229.3 (5 Mar 2016 01:21:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Mar 2016 01:21:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDHJ5C3AKGQE3MYOWDA@isocpp.org Sat Mar 05 02:21:19 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ac0uE-0000pY-Jm for gclcip-std-proposals@m.gmane.org; Sat, 05 Mar 2016 02:21:18 +0100 Original-Received: by mail-ig0-f200.google.com with SMTP id hb3sf15955361igb.2 for ; Fri, 04 Mar 2016 17:21:18 -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:sender :list-subscribe:list-unsubscribe; bh=AgRKMiEHHy//zUtW+uawvO9E2MwBVHsCfwh9mbNwZ8k=; b=fdAbP0YY3yR11YCyh0Rd0rda80GL+SR2Gt68cQ22mFx70GfPA6TyIMReR8lODuQrm1 acu9wV78qnwgzf/6BvK66lqN0tVccIiIWQcxrW+1yeMYo75DvpuJNVcEVhGjE+kbBEer GcrkAdMTuEScJMGTGHjrLx73J0oaWUIjG9pEqwVJkrbkEWblW8CRDAYhgHaJciL4aUOP iwRy/Q8/iNkbTWdhgK/zKoVcwuCqfFtTHtCNKMRUTK+dT3sO+pbaXzSvsh9zH7zX8qRc mXwIIGHqeOFH7+MX2a5zN4HZvwU91jgYqiPM8FiLedGwtyCW1TQZNl8M1KsRZpU/PDcr OKmQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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:sender :list-subscribe:list-unsubscribe; bh=AgRKMiEHHy//zUtW+uawvO9E2MwBVHsCfwh9mbNwZ8k=; b=TZU3yJhbANPQ2vbMegRtOqCx9oXD3DkZto5ZcqbCLEqml3dX6tebdV+hweEWuZbM/P fzvCWAHs3W9g2zHUMjH+vwbsIxgldTxYbe77FGQMcvYWGLBhSAQPQG4DQwWi78mu4qoW ZlwxfZpayaBCVJtSL8QeCy11Prg+wj11jK7HkscFyTuZ+JChRvMOhE9DQGBveFmUeesH 7B9yZZ7E3q+fNP0syMTjtC/759G5BCTaB1xkwA7KXr7PiUpPMFCmRKBw6L6eiR42NkWn eDD+JYeTwBLTxOvF0LCKhjTJn27kCx3Iaz+k5Um3oxdli8SO6XNsiuPRHMfxrRW7zi5X Ixsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:sender:list-subscribe:list-unsubscribe; bh=AgRKMiEHHy//zUtW+uawvO9E2MwBVHsCfwh9mbNwZ8k=; b=JZBpk7fVycbuKw54WSDvVQ2Sw9tkT8hn45hDtsSgXY3Q4BLvOx5EDMgeB8UExxFvaL xNYyOJra6rQbYTdoVyFFt/NWiK9WXHABcw7XWAopFpB6KKMcZgO3tjW0Tjh1mHoyGJ5R x2cpnBlRYu1Dcaccdpsz3NCZ/HyqSwBVc+VtMtqavS4A4iZhV54gc788rtJDvXM71rcv Cq56mq+FkFZn7JdgFAr0AKOyIdn9wBzhGjoy/n8gfzv15Ipic/ChRt1+g0/goTZjMsHh Xzf4OcoDGkYEbgn5JP5JZaDH6tfDm2yo7lcT4RjTn62gVK8BqB1FvnR+Mm8ct3lziNre fzlQ== X-Gm-Message-State: AD7BkJKCfByWQJS/HX5sQU2LNoQguXOIvn7J3y/vWa0PLAVVyt5eWiKNa4NKxksdrsrNUw== X-Received: by 10.107.17.102 with SMTP id z99mr2453931ioi.11.1457140877465; Fri, 04 Mar 2016 17:21:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.66.69 with SMTP id d5ls461185igt.12.canary; Fri, 04 Mar 2016 17:21:16 -0800 (PST) X-Received: by 10.50.103.68 with SMTP id fu4mr51326igb.9.1457140876406; Fri, 04 Mar 2016 17:21:16 -0800 (PST) In-Reply-To: <68af543f-b30b-447b-8709-56ccd847735a@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: Original-Sender: std-proposals@isocpp.org List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24944 Archived-At: ------=_Part_1474_1858167902.1457140875329 Content-Type: multipart/alternative; boundary="----=_Part_1475_1898901334.1457140875339" ------=_Part_1475_1898901334.1457140875339 Content-Type: text/plain; charset=UTF-8 On Friday, March 4, 2016 at 2:58:21 PM UTC-5, Evan Teran wrote: > > So it's not uncommon to see people write code like this: > > union T { > uint8_t bytes[sizeof(uint32_t)]; > uint32_t u32; > }; > > T x; > x.u32 = 0x11223344; > x.bytes[0] = 0xff;//undefined behavior :-( > > > Of course this is met with those who are trilled that it works, and just > as many others who are determined to avoid undefined behavior and would > like to avoid it at all costs. > Now that C++ has a proper attribute syntax. Has anyone considered having > an attribute which says "I want to pun this type, compiler please don't get > too clever here". > Well, the thing is, type punning is not forbidden to allow the compiler to be "clever". Or rather, not *just* for that. For unions, there's really not much "clever" that compilers can do with them. The C++ specification explains behavior. It specifies what the behavior of every expression ought to be. Now, consider your example. Even if we ignore compiler "cleverness"... what should the specification say the result of this operation will be? What will `x.u32` be after the two statements are executed? It's either undefined, implementation-defined, or well-defined. You want to rule out "undefined". So... what value does `x.u32` have? You say that it returns "the underlying bit-pattern interpreted as the appropriate type", but what does that *mean*? If I perform `x.u32 = 20;`, that is well-defined C++ code, and I know that following this statement, I can do `x.u32` and get back exactly 20. If I do `x.bytes[0] = 0x20;`, what do I get back with `x.u32`? What value is it? Of course by default we'd get the current rules about only having one > active member at a time and all that goodness, allowing optimizers to > assume that you won't do that and do clever things. And I recognize that > there would still be concerns about endianess and such, but at least we've > moved the issue from undefined behavior into "system specific" behavior, > which low level developers tend to be comfortable with. > In my experience, "low level developers" don't care that the above is undefined behavior; they'll do it anyway because they have no choice. -- 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/29412bcf-9f0b-4c1e-9ffb-b67943e2dfd1%40isocpp.org. ------=_Part_1475_1898901334.1457140875339 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, March 4, 2016 at 2:58:21 PM UTC-5, Evan Teran w= rote:
So it= 9;s not uncommon to see people write code like this:

union T {
=C2=A0 =C2=A0 uint8_t bytes[sizeof(uint32_t)];
=C2=A0 =C2=A0 uint32_t u32;
};

T = x;
x= .u32 =3D 0x11223344;<= /span>
x.bytes[0]<= span style=3D"color:#000"> =3D 0xff;//undefined behavio= r :-(


Of course= this is met with those who are trilled that it works, and just as many oth= ers who are determined to avoid undefined behavior and would like to avoid = it at all costs.
Now that C++ has a proper attribute syntax. Has = anyone considered having an attribute which says "I want to pun this t= ype, compiler please don't get too clever here".

Well, the thing is, type punning is not forbidden to allow = the compiler to be "clever". Or rather, not just for that.= For unions, there's really not much "clever" that compilers = can do with them.

The C++ specification explains behavior. It specif= ies what the behavior of every expression ought to be. Now, consider your e= xample. Even if we ignore compiler "cleverness"... what should th= e specification say the result of this operation will be?

What will = `x.u32` be after the two statements are executed? It's either undefined= , implementation-defined, or well-defined. You want to rule out "undef= ined". So... what value does `x.u32` have? You say that it returns &qu= ot;the underlying bit-pattern interpreted as the appropriate type", bu= t what does that mean?

If I perform `x.u32 =3D 20;`, that is = well-defined C++ code, and I know that following this statement, I can do `= x.u32` and get back exactly 20. If I do `x.bytes[0] =3D 0x20;`, what do I g= et back with `x.u32`? What value is it?

Of = course by default we'd get the current rules about only having one acti= ve member at a time and all that goodness, allowing optimizers to assume th= at you won't do that and do clever things. And I recognize that there w= ould still be concerns about endianess and such, but at least we've mov= ed the issue from undefined behavior into "system specific" behav= ior, which low level developers tend to be comfortable with.

In my experience, "low level developers"= don't care that the above is undefined behavior; they'll do it any= way because they have no choice.

--
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/29412bcf-9f0b-4c1e-9ffb-b67943e2dfd1= %40isocpp.org.
------=_Part_1475_1898901334.1457140875339-- ------=_Part_1474_1858167902.1457140875329-- .