From owner-sc22wg5@open-std.org Sat Mar 26 19:02:17 2011 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 466A3C178DC; Sat, 26 Mar 2011 19:02:17 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mk-filter-4-a-1.mail.uk.tiscali.com (mk-filter-4-a-1.mail.tiscali.co.uk [212.74.100.55]) by www2.open-std.org (Postfix) with ESMTP id 65C41C178DA for ; Sat, 26 Mar 2011 19:02:13 +0100 (CET) X-Trace: 588417996/mk-filter-4.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/79.74.77.161/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 79.74.77.161 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlECADwpjk1PSk2h/2dsb2JhbAAMmF2WYLllhWkEjHaDSA X-IronPort-AV: E=Sophos;i="4.63,248,1299456000"; d="scan'208";a="588417996" Received: from 79-74-77-161.dynamic.dsl.as9105.com (HELO [192.168.1.2]) ([79.74.77.161]) by smtp.tiscali.co.uk with ESMTP; 26 Mar 2011 18:02:12 +0000 Message-ID: <4D8E2A23.8050805@stfc.ac.uk> Date: Sat, 26 Mar 2011 18:02:11 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13 MIME-Version: 1.0 To: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.4420) WG informal ballot References: <20110303174947.DD0CAC3BA01@www2.open-std.org> <20110325193010.B3704C178DA@www2.open-std.org> In-Reply-To: <20110325193010.B3704C178DA@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Jim Xia wrote: > > > > > Please answer the following question "Is N1814 ready for forwarding > to SC22 > > as the PDTR?" in one of these ways. > > > > 1) Yes. > > 2) Yes, but I recommend the following changes. > > 3) No, for the following reasons. > > 4) Abstain. > > > > No, for the following reasons > > 1.) allow the same C descriptor to be used in CFI_setpointer(). This is > a bad idea to begin with, and will cause grief in compiler optimizers. Do you mean that ptr_dv and source should not be allowed to point to the same C descriptor? Adding such a restriction seems reasonable to me. > 2.) there are apparent overlapping functionality between > CFI_setpointer() and CFI_section(). It's confusing to understand exactly > which does what, or when to use which. Please look at what I have proposed in my vote. Is this OK? > It's also not clear to me which > one will result in zero-based array section or one-based array > section. I don't see the problem. The lower bounds are held explicitly in the C descriptor. > 3.) allow Fortran ALLOCATABLE variables to be allocated on one side (C > or Fortran) and then deallocated from the other side. This likely will > cause many implementation difficulties. I expect the vendor to make CFI_allocate and CFI_deallocate call Fortran code to do the actual allocations and deallocations, so that they all happen on the Fortran side. Best wishes, John.