220 35007 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Edward Catmur' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: standard attribute for unions to pun types? Date: Thu, 19 Oct 2017 02:28:39 +0100 Lines: 175 Approved: news@gmane.org Message-ID: References: <68af543f-b30b-447b-8709-56ccd847735a@isocpp.org> <5df63738-279b-44ae-be59-6e729577000d@isocpp.org> <9f16bfc4-8b7b-4108-bff9-1d0c2147edd6@isocpp.org> <81a9a9de-9fc7-480c-8cd2-263e2c4fae7d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045f1a9aa61656055bdc46fd" X-Trace: blaine.gmane.org 1508376526 10656 195.159.176.226 (19 Oct 2017 01:28:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 19 Oct 2017 01:28:46 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDZLZTXF7UJBBSH7T7HQKGQEAGQYYQI@isocpp.org Thu Oct 19 03:28:40 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f200.google.com ([209.85.128.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4zdR-00014x-L1 for gclcip-std-proposals@m.gmane.org; Thu, 19 Oct 2017 03:28:33 +0200 Original-Received: by mail-wr0-f200.google.com with SMTP id o44sf3283470wrf.0 for ; Wed, 18 Oct 2017 18:28:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1508376521; cv=pass; d=google.com; s=arc-20160816; b=wkEprbaqvkCMxhoe0bUFg2vCya7FdMklqkVD5rfO2IcIk8ypzE35mA0+oU8bj26q3V N1CHkyi07ZpQl5HqN0qlpMERXIuUVhx25vmwv+WOA9eCbpeyd/yJwKgZjNF6efgSy7sm UbRUEdURzesKJdsImG2Y7r2lk7pxW0GAB0YT43IQFZUcbjyx/j5WX4U3iwu0V8wEc8O6 YVWacYj+MyVDPuQSYx+B2IqR91pb1ZhDe6PEXaxygCDjwyGJaBgYvm7/EiSlpkF7rLEu 8FKui6SvYL7MgJlsY7EtoiUyecR51R/wlxvmu/qr9HqhQuFjygTe265d+3Aa3aGD1ydf T+SQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=689lQdP/u/hlQjT3Kj3vA+lcKl3dH/d98OPfc6QfxtA=; b=IjiVFJTMqdtqujGHBp0vxPZ0FpYzYe9rtT44hrM1xRMHZc255JN26ia50VRHOY9hIR Es1ZfG4HP/B14FLjs+NuoSvYsWL4Ww14b5LU1I1TCLyhwYrkL0fYLC1lUHeV01Q02t5L E2ciDT3YIXLUe+WM94codKV9NkGoJYX+KeW+slVCMmqA3WyiEPE9RG9SVJdsckUzoq/o /uRwDyj+ae5VEJ3Zn/86eWi+Tf6CJEIZ1smbVFWjugg4wtAadg4C83Nc4lGKJZIS44zZ Ia6iyXOZbBKboP2Rao+nhBh+EG/ObrtAT8FssYPr9amAZZWgneyEy5gduIB++FX6TWGy gt0A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=G9mRlZng; spf=pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=689lQdP/u/hlQjT3Kj3vA+lcKl3dH/d98OPfc6QfxtA=; b=ST/F7+h0Iuzu6RzU8RnY0BGiJK0AU3UQBo/AWBujUpWrY45Atq0Zprh2WsvQ2E5Omg H6ndqUZU52FjuU6sYYizHQ2dmPgZhQ4tZSAzQ5qO/3wq97Xizi4HjZtBnqPQE/VpLJdC sn1JXR6EJD5vrB5KKkPAVZqOBVRX+4hhF3YZSfZbDpcWNA4/Cjf66fA5QBcuk9Il16X0 hLEy6xWSnQ7g3xO+kdVnyI0APJZV+33kCE1D0IUpQgSIi4HsQ7SkGGsJb0+uu+SAIOiJ CEXiRFgKF14fQGZVnKPJLFU0kw9cWJF6htGQRghPkJIZxe0A+BNA0sOQjU4dLN0a9yKG +2XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=689lQdP/u/hlQjT3Kj3vA+lcKl3dH/d98OPfc6QfxtA=; b=nRfl0Mz7n0vc8NOznVOHqe7OXFIX8tg/InM6oTQfyNpWfipxrcibsoD3/wUv0DuAYh eIpfB1J0tFUiSoJ8+sKeSlY2p5KKZTvFbbyTllZSgBaclDUn3Zs05U0rtUQnMrpvo9yZ w8pDDEKoubVqCcmBVh6iZAOavmiN8CEczFQggBV4mq53CfTqWpNjgO2d4DWEi8TFeERd PLbkja/AZ4LOHEsz8cDaWNH3Col0oBZFjmqKqtxKbS2RKqo7EKamqVr/OWntmR97SxCj nIa+y+jKLxkCqYVon1TLr6ybu5tGXRDlIaqDOkHEhXdjivqSrCTkICMhpkn8OQz6naQK f7NA== X-Gm-Message-State: AMCzsaVIlZmNRZ5HSQ8EXwqlwJkGDyhKgm37rXfBouciuupkP6FtJv8S 0JK/QS2plsp6rdq39fFBPLg= X-Google-Smtp-Source: ABhQp+SPPoRylBa+2KXFxifKyvprFgqa5M+piiM+l74bmIz/GMBICmFvxMk1PCNGez5KfbHi0tARRA== X-Received: by 10.28.128.140 with SMTP id b134mr21124wmd.3.1508376521068; Wed, 18 Oct 2017 18:28:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.162.137 with SMTP id s9ls1626256wra.7.gmail; Wed, 18 Oct 2017 18:28:40 -0700 (PDT) X-Received: by 10.28.109.23 with SMTP id i23mr186737wmc.32.1508376520120; Wed, 18 Oct 2017 18:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508376520; cv=none; d=google.com; s=arc-20160816; b=olBZi5OxwLwEBEAX+7fEkHKhWO/ofR6W2yCqeglvjnLBjM1QowTc1bn5VeW5IhB8/s cUiximhIOq1OJZVKl98ketbb9sZv9dD2UnzyNUeh8o8uok/dHTDo+dbxOGIBdacGQ2A+ X7rVJ4NUcwydxfeGDYkAoX2qkj2gFp5QBvEjPJTU/2NuaCLR9AHG8A0DpV/v3fSS7MVK wpjY2yfxUGtK/UQuhy/UszhTxR18tLkwsMjFVDA0K8zbXWca9SWAUHTwEEjcaKRjSGnr WBCK1b9rzkbjNPifAd6DhOg+1YrMihc6javCHgNv53UsWk0z6DDrXmzbJ9ITmLnePYLa iITA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=Kg08yFBTzad464FINnnQ325IKGU3BIQBiUa1fq3dGfA=; b=ALb1vgXj4n4PAe67plI6/5YkPD2cEqvj290SeZNTioojDzoIjJ0vpyB68/Sye66eTq jXUS7bUkY4J/4Cvv87BhFjEWjm0lG88NXpmLQCgU0/CYTKA6BzZPIHB9HZEaMoJseYic TUHSfpn/lib8jYJCTt5fo/5wVWEkg3KikQH+TbiszAiU9jl3uJTTZC0pp+JAlTaY4tVd lLKB/Kfjvqk/FUuD0SNh7jh1InDBBiqAQRhBvn/DGdkIOUyrICSj6IO1wx1ZgXvtcbLp q1s6ODq4JK6tfCEpwoLPmPwmxRC+i8vsfLlreS/r7XHuJ/EpzCF8LNK4AHrN8gkIn6Tb 8Itw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=G9mRlZng; spf=pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id q15sor5701929wra.61.2017.10.18.18.28.40 for (Google Transport Security); Wed, 18 Oct 2017 18:28:40 -0700 (PDT) Received-SPF: pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.223.164.138 with SMTP id g10mr7930156wrb.134.1508376519774; Wed, 18 Oct 2017 18:28:39 -0700 (PDT) Original-Received: by 10.28.52.145 with HTTP; Wed, 18 Oct 2017 18:28:39 -0700 (PDT) Original-Received: by 10.28.52.145 with HTTP; Wed, 18 Oct 2017 18:28:39 -0700 (PDT) In-Reply-To: <81a9a9de-9fc7-480c-8cd2-263e2c4fae7d@isocpp.org> X-Original-Sender: ecatmur@googlemail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=G9mRlZng; spf=pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com X-Original-From: Edward Catmur 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:35007 Archived-At: --f403045f1a9aa61656055bdc46fd Content-Type: text/plain; charset="UTF-8" On 19 Oct 2017 01:44, "Myriachan" wrote: On Wednesday, October 18, 2017 at 5:17:51 PM UTC-7, Edward Catmur wrote: > On 19 Oct 2017 01:00, "Myriachan" wrote: > > The optimizer people don't like us taking pointers to union members even > when type punning isn't involved at all: > > https://bugs.llvm.org/show_bug.cgi?id=34632 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82224 > > Anyway, the question is really about what we're going to do now. We can't > go back and change how struct sockaddr_in6, OSVERSIONINFOEXW, etc. work. > > > That's up to the respective vendors. If they need to add private > attributes to ensure that these quasi-union types continue to work as > documented, then so be it. But there's no need to require such facilities > to exist on platforms that don't have to support these APIs. > > Name one "hosted" (rather than "freestanding") platform that doesn't use structures/unions in this way somewhere in their API. Hah. Well, if there's existing practice, there's something to standardize. But I don't think much more than the existing common initial sequence rule is really required. Note that in the case of sockaddr, all the compiler needs is to permit > casts between sockaddr, sockaddr_storage and the various protocol address > types. There is no particular need for unions to be involved per my > understanding. > > From compiler writers' perspectives, there is very little difference between these unions and structs with a common initial sequence that get reinterpret_cast among each other. As an example, comment 20 in the link I gave above shows Clang messing up when no unions are involved, in a similar situation to how struct sockaddr works with sa_family. Sure, once you've got pointers to different elements of the same union. Casting between those pointers is problematic at present. This is still only common initial sequence stuff, though; there's no type punning at scalar level. Melissa -- You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this topic, visit https://groups.google.com/a/ isocpp.org/d/topic/std-proposals/mPFd9uLsus8/unsubscribe. To unsubscribe from this group and all its topics, 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/81a9a9de-9fc7-480c- 8cd2-263e2c4fae7d%40isocpp.org .. -- 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/CAJnLdOaiYo9b791yyGcRoBhfoK1Nm%2BLP-ZgphDGO7Wxx1rOg6A%40mail.gmail.com. --f403045f1a9aa61656055bdc46fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 19 Oct 2017 01:44, "Myriachan" <myriachan@gmail.com> wrote:
On Wednesday, October 18, 2= 017 at 5:17:51 PM UTC-7, Edward Catmur wrote:
On 19 Oct 2017 01:00, "Myriachan" <myri...@gmail.com> wrote:
The optimizer people don't like us taking pointers to= union members even when type punning isn't involved at all:


Anyway, the question = is really about what we're going to do now.=C2=A0 We can't go back = and change how struct sockaddr_in6, OSVERSIONINFOEXW, etc. work.
=

That's up to the respective vendors. If they need to add = private attributes to ensure that these quasi-union types continue to work = as documented, then so be it. But there's no need to require such facil= ities to exist on platforms that don't have to support these APIs.=C2= =A0


Name one "hosted" (rather than "freestanding") p= latform that doesn't use structures/unions in this way somewhere in the= ir API.

Hah. W= ell, if there's existing practice, there's something to standardize= .. But I don't think much more than the existing common initial sequence= rule is really required.=C2=A0


<= /div>
Note that in the case of sockaddr, all the compiler = needs is to permit casts between sockaddr, sockaddr_storage and the various= protocol address types. There is no particular need for unions to be invol= ved per my understanding.=C2=A0


=
From compiler writers' perspectives, there is very little di= fference between these unions and structs with a common initial sequence th= at get reinterpret_cast among each other.=C2=A0 As an example, comment 20 i= n the link I gave above shows Clang messing up when no unions are involved,= in a similar situation to how struct sockaddr works with sa_family.
<= div>

=
Sure, once you've got pointers to different elements = of the same union. Casting between those pointers is problematic at present= .. This is still only common initial sequence stuff, though; there's no = type punning at scalar level.=C2=A0


Melissa
=

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/m= PFd9uLsus8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/81a9= a9de-9fc7-480c-8cd2-263e2c4fae7d%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJnLdOaiYo9b79= 1yyGcRoBhfoK1Nm%2BLP-ZgphDGO7Wxx1rOg6A%40mail.gmail.com.
--f403045f1a9aa61656055bdc46fd-- .