From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 20 16:28:33 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 2BE1735693F; Tue, 20 Mar 2012 16:28:33 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by www.open-std.org (Postfix) with ESMTP id 32648356837 for ; Tue, 20 Mar 2012 16:28:31 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKT2iiHoOrOZ39ua0fPsyZAVxshgm16Fxo@postini.com; Tue, 20 Mar 2012 08:28:32 PDT Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.1.355.2; Tue, 20 Mar 2012 10:18:48 -0500 Message-ID: <4F689FE4.4050806@cray.com> Date: Tue, 20 Mar 2012 10:19:00 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4666) [ukfortran] AW: Informal WG5 ballot on new draft DTS 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> In-Reply-To: <20120320131906.BBAC53568F0@www.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 On 3/20/12 8:19 AM, N.M. Maclaren wrote: > On Mar 20 2012, N.M. Maclaren wrote: >> On Mar 19 2012, Bader, Reinhold wrote: >>> Malcolm Cohen wrote >>>> 8.4, Note 8.11 [p29] Do we really have to say "C programmers should >>>> note"? In any case it is far too weakly worded (Reinhold's version >>>> does not really improve this), here is my suggestion: "A C function >>>> that modifies a C descriptor other than as permitted by this >>>> Technical Specification will cause undefined behaviour." BTW re My main interest is whether we all agree with the wording change above (apart from spelling). >>>> 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. >> 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. 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. >> As the person to blame for perpetrating that vague evasion, let me try >> to explain why I did it :-( > > Oops. That may still be confusing. I was trying to address Reinhold's > concern, only more generally. It isn't JUST the modification of > descriptors in other ways, but the creating of perfectly valid C pointers > and then creating a new descriptor from them. If this ends up creating > two Fortran objects that the Fortran compiler 'knows' are distinct but > aren't, chaos will sometimes ensue. > Unless this second object is accessible in Fortran by, for example, being associated with an argument in a call to a Fortran procedure, the newly created descriptor could be harmless. But I think the descriptor issue is an extra complication here - equally bad mischief is possible with ordinary pointers. > For example, creating a logical descriptor from one passed as a complex > descriptor. That's quite legal in C but, because EQUIVALENCE is forbidden > for arguments, optimising compilers may assume that it can't happen in > that way. > As long as the new descriptor is localized to the C function, the compiler that matters is the C compiler, which is not that optimizing. > An even worse one is to use the C interface to produce the class of > intrinsic that Fortran lacks - i.e. a variable-semantics one (like array > sections) rather than value-semantics. That would enable someone to > provide the originally requested facility of creating a slanted array > section, such as a diagonal. > > I am certain that we need SOME way of saying "don't go there". > Agreed. We just need to agree where "there" is. Cheers, Bill > > Regards, > Nick Maclaren. > > _______________________________________________ > J3 mailing list > J3@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3 -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101