From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 20 14:19:06 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 A44AD35692E; Tue, 20 Mar 2012 14:19:06 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id 2F77B3568DB for ; Tue, 20 Mar 2012 14:19:05 +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]:42053) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1S9yxt-0008V6-QR (Exim 4.72) (return-path ); Tue, 20 Mar 2012 13:19:05 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1S9yxt-0007FZ-4o (Exim 4.67) (return-path ); Tue, 20 Mar 2012 13:19:05 +0000 Received: from [131.111.10.32] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 20 Mar 2012 13:19:05 +0000 Date: 20 Mar 2012 13:19:05 +0000 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4663) AW: Informal WG5 ballot on new draft DTS Message-ID: In-Reply-To: References: <20120219131214.268A1356998@www.open-std.org> <20120319050226.88C14356822@www.open-std.org> <20120319134001.616DE356854@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, 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 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. > >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. 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. 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". Regards, Nick Maclaren.