From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Thu Mar 30 03:33:49 2017 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 97C3E357125; Thu, 30 Mar 2017 03:33:49 +0200 (CEST) Delivered-To: sc22wg14@open-std.org X-Greylist: delayed 649 seconds by postgrey-1.34 at www5.open-std.org; Thu, 30 Mar 2017 03:33:48 CEST Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 4809D356DD0 for ; Thu, 30 Mar 2017 03:33:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490837628; x=1522373628; h=from:to:subject:date:message-id:mime-version; bh=9pDhusoGvMU25FmukXFnQ57ysYeHULrMk6GrnCUKcUI=; b=QwgXR3AKMsK0BfaXgCsAwed57boAKhzCBH88n43N2128J8AavjQfKrrw oVlKu5vVNgh9WilPYsWMERB7HSB4Og==; Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 18:22:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,244,1486454400"; d="scan'208,217";a="71763894" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga004.jf.intel.com with ESMTP; 29 Mar 2017 18:22:53 -0700 Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 29 Mar 2017 18:22:53 -0700 Received: from orsmsx103.amr.corp.intel.com ([169.254.5.19]) by ORSMSX153.amr.corp.intel.com ([169.254.12.29]) with mapi id 14.03.0319.002; Wed, 29 Mar 2017 18:22:53 -0700 From: "Nelson, Clark" To: ISO C Subject: My approach to DR 499 and 502 Thread-Topic: My approach to DR 499 and 502 Thread-Index: AdKo88JtjBZQ+FPdTa6vpM0Pp1hwVw== Date: Thu, 30 Mar 2017 01:22:52 +0000 Message-ID: <38C37E44FD352B44ABFC58410B0790D0BE507B9F@ORSMSX103.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_38C37E44FD352B44ABFC58410B0790D0BE507B9FORSMSX103amrcor_" MIME-Version: 1.0 Sender: owner-sc22wg14@open-std.org Precedence: bulk --_000_38C37E44FD352B44ABFC58410B0790D0BE507B9FORSMSX103amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The questions that arise in these DRs are all about the interpretation of t= he phrase "considered to be members of the containing structure or union" i= n 6.7.2.1p13, which concerns anonymous structures and unions. My mental model of what that consideration implies has always been that it = has to do with the interpretation of member selection expressions, and more= specifically the lookup of member names. Remember that the names of members of a given structure or union type have = a specific name space, and as a result, a name can be used to access a memb= er even in the scope of a local variable with the same name: struct X { int i; }; void f(struct X *p) { int i; i =3D p->i; } This example is perfectly valid, and the two uses of the identifier "i" are= disambiguated by the fact that they come from different name spaces. The sense in which a member of an anonymous structure or union needs to be = treated like a member of the containing type (in order for anonymous struct= ures to work) is that its name needs to be available as if it were declared= in the containing type. From that perspective, I would consider the following to be along the lines= of an editorial clarification: An unnamed member of structure type with no tag is called an anonymous stru= cture; an unnamed member of union type with no tag is called an anonymous u= nion. The names of members of an anonymous structure or union are added to= the name space of the containing structure or union. This applies recursiv= ely if the containing structure or union is also anonymous. I believe that this (or something like it) would fix DR 499; it would be co= nsistent with the answer from the 2016-10 meeting ("The storage does not ov= erlap."), in that there would no longer be ambiguity about whether the imme= diate members of the structure are allocated as if in the structure or the = union. However, I think it would not be consistent with the answer to DR502 from t= he 2016-10 meeting ("defining a flexible array as the sole member of an ano= nymous struct is permitted"). Personally, I wouldn't consider that to be a problem. I disagree with that = answer, because it isn't consistent with my own mental model of "considered= to be a member". I also don't consider the idiom in question to be importa= nt enough to motivate me to change my mental model. (The 2016-10 minutes record no discussion to justify that answer; just "Cla= rk thinks his clarification on N2038 may also resolve DR 502.". That would = be true only if a reversal would be acceptable as a kind of resolution.) --_000_38C37E44FD352B44ABFC58410B0790D0BE507B9FORSMSX103amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The questions that arise in these DRs are all about the interp= retation of the phrase “considered to be members of the containing structure or union” in 6.7.2.1p13, which concerns = anonymous structures and unions.

My mental model of what that consideration implies has always = been that it has to do with the interpretation of member selection expressions, and more specifically the lookup of member n= ames.

Remember that the names of members of a given structure or uni= on type have a specific name space, and as a result, a name can be used to access a member even in the scope of a local variabl= e with the same name:

struct X {

    int i;

};

 

void f(struct X *p)

{

    int i;

    i =3D p->i;

}

This example is perfectly valid, and the two uses of the ident= ifier “i” are disambiguated by the fact that they come from different name spaces.

The sense in which a member of an anonymous structure or union= needs to be treated like a member of the containing type (in order for anonymous structures to work) is that its name needs to= be available as if it were declared in the containing type.

From that perspective, I would consider the following to be al= ong the lines of an editorial clarification:

An unnamed member of structure type with no tag is called an anonymous structure; an unnamed member of union type with no tag is = called an anonymous union. The names of members of an anonymous structure or union are  added to the name space of the containing structure= or union. This applies recursively if the containing structure or union is also anonymous.

I believe that this (or something like it) would fix DR 499; i= t would be consistent with the answer from the 2016-10 meeting (“The storage does not overlap.”), in that there would= no longer be ambiguity about whether the immediate members of the structur= e are allocated as if in the structure or the union.

However, I think it would not be consistent with the answer to= DR502 from the 2016-10 meeting (“defining a flexible array as the sole member of an anonymous struct is permitted”).=

Personally, I wouldn't consider that to be a problem. I disagr= ee with that answer, because it isn't consistent with my own mental model of “considered to be a member”. I als= o don't consider the idiom in question to be important enough to motivate m= e to change my mental model.

(The 2016-10 minutes record no discussion to justify that answ= er; just “Clark thinks his clarification on N2038 may also resolve DR 502.”. That would be true only if a reversal wou= ld be acceptable as a kind of resolution.)

 

--_000_38C37E44FD352B44ABFC58410B0790D0BE507B9FORSMSX103amrcor_--