From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 31 11:31:19 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 C109C3569AA; Fri, 31 Aug 2012 11:31:19 +0200 (CEST) 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 659BF3568F2 for ; Fri, 31 Aug 2012 11:31:18 +0200 (CEST) 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-1.csi.cam.ac.uk ([131.111.8.51]:47593) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1T7NZO-0000rf-RE (Exim 4.72) (return-path ); Fri, 31 Aug 2012 10:31:18 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1T7NZO-0008Hh-Db (Exim 4.72) (return-path ); Fri, 31 Aug 2012 10:31:18 +0100 Received: from [91.125.224.214] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 31 Aug 2012 10:31:18 +0100 Date: 31 Aug 2012 10:31:18 +0100 From: "N.M. Maclaren" To: Malcolm Cohen , sc22wg5 Subject: Re: [ukfortran] (SC22WG5.4744) Comments on comments on Ballot 3 on Fortran 2008 interpretations Message-ID: In-Reply-To: <20120831064101.E6D09356925@www.open-std.org> References: <20120804040444.460F63568DA@www.open-std.org><20120806212738.70CE53568F2@www.open-std.org><20120807182349.20E743568F8@www.open-std.org> <20120818115719.C0FDD35691B@www.open-std.org> <20120831064101.E6D09356925@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk I apologise for the length of this, but there are some misunderstandings about my response, probably because I wasn't explicit enough. On Aug 31 2012, Malcolm Cohen wrote: > re F03/0053. > >No it does not state that. I am boggled by this assertion! p1 says > "... is interoperable if it has ..." >i.e. It Most Emphatically Does Not Say "ONLY IF". I was referring to paragraph 2, but left the "2" out. Sorry. > It is p2 that says that a derived type interoperates with a C struct *if > and only if* it has the BIND attribute. That means that C_PTR and > C_FUNPTR ***CANNOT*** have the BIND attribute, because ***they do not > interoperate with any C struct***. Thank you for pointing that out - I accept that I was careless when reading that, and have changed my vote. I still think that this is a technically bad solution, but that is a different matter, and not something to address in an interpretation. ><<< >>I also agree with John Reid on question (2), and regard the liberty to >>break the privacy restrictions by using interoperability as a defect in >>the standard. >>>> > > Well good then, because you cannot "break the privacy restrictions" that > way. The user cannot put BIND(C) on the derived types in the library he > is calling. If it's his own library, *HE CAN DO ANYTHING HE LIKES > ANYWAY*. That was and is not my point. There are a large number of restrictions in the Fortran standards (and in most others, including C and C++) which are there solely to assist the enforcement of software engineering standards and to keep rules simple. Not EVERYTHING has to define extra functionality. In this case, PRIVATE is a rigorously checked feature except for SEQUENCE and BIND(C); SEQUENCE is usually discouraged and not essential, but BIND(C) is another matter. > The Fortran PRIVATE attribute has never ever been this super-restrictive > thing that you and John are imagining. For SEQUENCE types (and thus > BIND(C) types) there are multiple ways of "seeing past the curtain", in > these cases all PRIVATE does is to hide the name when accessing things of > the type outside of a module with a definition. This is not as useful as > PRIVATE on an extensible type, but still has some uses. Agreed. > Once again, with feeling: BIND(C) is merely the interoperable version of > SEQUENCE, and therefore has basically the same allowances and limitations > as SEQUENCE. There is no defect here. I did not mean that there is a defect in the wording, but in the design, and I stand by that. I agree that correcting design defects is not an appropriate use of interpretations. >re F03/0065 > >David Muxworthy writes: ><<< >The interpretation hinges on whether 'values' in F2003 section 7.1.8.5 >(and hence F2008 7.1.5.5.2) refers to mathematical values or >computational values. >>>> > > The clear meaning of "all possible values" is "all values that are > possible". Otherwise we'd have simply written "mathematically equivalent" > if that is what we meant. I am sorry, but that does not make sense. There is a continuum from mathematically and computationally different values down to ones that have different bit-patterns but represent the same number and cannot be distinguished by any numeric or quasi-numeric operation specified in either the Fortran or C standards. If you were to say that the clear meaning of "all possible values" is "all values that are distinguishable using defined operations", I might agree. But that STILL doesn't specify it precisely. We had this argument at length in WG14, with regard to pointer equivalence, but we failed to resolve it and the C standard was left "constructively ambiguous". But let's stick with arithmetic values, which are much simpler, but still fiendishly complicated. Inter alia, are two values different if (a) they are numerically different, (b) they are computationally different or (c) they are representationally different? All three are different concepts in C99 and IEEE 754, heaven help us. There is a particular problem with the last (which is what many people would understand by "all values that are possible) in that such values are not always preserved by assignment or even argument passing and in function results, but have been used by some programs for passing out-of-band-data. > I find it somewhat boggling to hear 3 users say that they are happy to > get the wrong answer for a relational operator, when no vendors are > complaining that their hardware cannot do it fast enough. I used a > mini-computer in the 70s that did not have a comparison instruction, but > then it did not have multiply, divide, or even subtraction either! But > Fortran still required all those to work. These days, even my washing > machine has hardware to do a correct comparison! That was not my reason for objecting, though I accept that I did not make it clear. It was that this is clarifying one aspect without addressing the issue of whether that makes others harder to clarify. At least one of the questions of exactly what a value is, and whether and how this wording interacts with intrinsics like MAX, needs addressing properly. >re F03/0121: > > One might plausibly argue that we are being more helpful here than we > need to. Except for the fact that we are stating that something is required when it is merely the usual implementation, I agree. Just dropping that paragraph would address my comment. >Nick opined: ><<< >is a common myth in among C and C++ and even in informative text in the >standards that volatile implies this semantic >>>> > >If informative text in the standard implies this semantic, that is a clear >indication of the intent of the C committee. > ><<< >but it is not justified by their normative text, >>>> > >That is your opinion. You might or might not be right. My >understanding of the normative text is otherwise i.e. the same as the >informative implication. I might or might not be right. Under the >circumstances, since this is the Fortran committee not the C committee, >we should take the informative text as being correct rather than what >some of the barracks-room lawyers say. Sorry, BUT .... As you know, I was on the UK C panel during the standardisation of both C90 and C99. The UK tried long and hard to get this situation sorted out during that of C90, but failed; we raised it again during that of C99. In the former, a majority of WG14 agreed that it did not have this semantic, but it was deliberately not specified to assist implementors who did not want to provide it; in the latter, it was about evens, but no progress was made for the same reason. It was also raised by some people who had systems where it did NOT work, but I cannot now find the historical corrigenda, to see if it was ever formally answered as an interpretation. There are a large number of places in the C standard where informative text is used to specify something, precisely because no consensus could be reached and/or because the feature is not always implementable. There are also places where it actually conflicts with normative text. This was a frequently raised issue on WG14 and is on WG21. If you were referring to 9899:2011, you would be correct, because there has been a change between C99 and C11 in 5.1.2.3 Program execution (paragraphs 5 and 6 in the two versions). Regards, Nick Maclaren.