From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 20 17:55:14 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 4B67A356941; Tue, 20 Mar 2012 17:55:14 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106]) by www.open-std.org (Postfix) with ESMTP id AD21E3568F0 for ; Tue, 20 Mar 2012 17:55:12 +0100 (CET) Received: from postout1.mail.lrz.de ([10.156.6.18] [10.156.6.18]) by mailrelay1.lrz-muenchen.de with ESMTP; Tue, 20 Mar 2012 17:55:03 +0100 Received: from BADWLRZ-SWHBT2.ads.mwn.de (BADWLRZ-SWHBT2.ads.mwn.de [IPv6:2001:4ca0:0:108::126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPS id E22F9C5823; Tue, 20 Mar 2012 17:55:02 +0100 (CET) Received: from BADWLRZ-SWMBX1.ads.mwn.de ([fe80::11b4:b130:c4e2:2d0e]) by BADWLRZ-SWHBT2.ads.mwn.de ([fe80::5951:9dc3:7b2b:14ba%13]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 17:55:02 +0100 From: "Bader, Reinhold" To: "longb@cray.com" , sc22wg5 Subject: AW: (SC22WG5.4667) (j3.2006) [ukfortran] AW: Informal WG5 ballot on new draft DTS Thread-Topic: (SC22WG5.4667) (j3.2006) [ukfortran] AW: Informal WG5 ballot on new draft DTS Thread-Index: AQHNBq4i2QhzVpocmUyqFTlFXpXc7ZZzYhCQ Date: Tue, 20 Mar 2012 16:55:01 +0000 Message-Id: <166ED263DF83324D9A3BA67FB6772B2B4800C236@BADWLRZ-SWMBX1.ads.mwn.de> References: <20120219131214.268A1356998@www.open-std.org> <20120319050226.88C14356822@www.open-std.org> <20120319134001.616DE356854@www.open-std.org> <20120320131906.BBAC53568F0@www.open-std.org> <20120320152833.62F5B356940@www.open-std.org> In-Reply-To: <20120320152833.62F5B356940@www.open-std.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4ca0:0:f031::3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk [...] >=20 >=20 > >>>> Reinhold's version - pointer arithmetic beyond the limits of an > >>>> object is already undefined behaviour in C, so I think we need not > >>>> (and should not) say anything about that. > >>> > >>> I was targetting the case of calculating a perfectly valid C address > >>> which happens to not be part of the described Fortran object e.g., in > >>> the case of a discontiguous array. Since the /base_addr/ is exposed, > >>> there is a quite good chance of this happening to the unsuspecting C > >>> programmer. > >> >=20 > This is a different issue than what is covered by the new wording above. > Without any modification of any C descriptor a user could (but should > not) add an offset to a copy of the base address in a descriptor that > becomes a pointer to a data entity (memory location) that is not part of > the described object. This would not happen in a Fortran procedure, but > given the "Wild Wild West" nature of C pointers, it could in a C > function. I think the original wording was intended to cover this case. It could be understood to do this by someone who was involved writing the T= S :-) > The calling Fortran procedure might have made optimizations based on > the assumption that the (now wrongly accessed in the C function) > variable would not change during execution of the C function. I think it is not only an optimization issue. Overwriting data via a derefe= rence to an incorrectly computed offset is technically possible within C, but sho= uld=20 be banned for at least such entities created within Fortran. Actually, some= =20 additional normative text may be required. Perhaps something like "References and definitions to an entity accessed via an address computed from the /base_addr/ member of a C descriptor are valid if and only if thi= s address can also be computed by invocation of CFI_address with that descri= ptor or another descriptor created as a subobject of it as its /dv/ argument, a= nd the type to which it is cast is consistent with the /type/ member of that descriptor argument." would do the job? Regards Reinhold