From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 20 17:22:23 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 984083568F0; Tue, 20 Mar 2012 17:22:23 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by www.open-std.org (Postfix) with ESMTP id 72607356836 for ; Tue, 20 Mar 2012 17:22:23 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42508) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:nmm1) id 1SA1pG-0001id-Yj (Exim 4.72) for sc22wg5@open-std.org (return-path ); Tue, 20 Mar 2012 16:22:22 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1SA1pG-0002Pi-NA (Exim 4.67) for sc22wg5@open-std.org (return-path ); Tue, 20 Mar 2012 16:22:22 +0000 Received: from [131.111.10.32] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 20 Mar 2012 16:22:22 +0000 Date: 20 Mar 2012 16:22:22 +0000 From: "N.M. Maclaren" To: sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4667) (j3.2006) AW: Informal WG5 ballot on new draft DTS Message-ID: In-Reply-To: <20120320152833.62F5B356940@www.open-std.org> 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> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Mar 20 2012, Bill Long wrote: > >>> 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. Not really. I am thinking of Fortran creating a (say) complex object with the target attribute, passing it to C, and that calling Fortran with a logical argument with the pointer attribute, in a context where the original object is visible. Because a logical pointer can't refer to a complex target in Fortran (can it?), it could optimise on the basis of that assumption. Bang! >> 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. Yes. That's not the problem. Regards, Nick Maclaren.