From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Aug 31 12:35:38 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 483E23569AB; Fri, 31 Aug 2012 12:35:38 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 304 seconds by postgrey-1.34 at www5.open-std.org; Fri, 31 Aug 2012 12:35:37 CEST Received: from bay0-omc2-s8.bay0.hotmail.com (bay0-omc2-s8.bay0.hotmail.com [65.54.190.83]) by www.open-std.org (Postfix) with ESMTP id 396D935699F for ; Fri, 31 Aug 2012 12:35:36 +0200 (CEST) Received: from BAY166-DS17 ([65.54.190.123]) by bay0-omc2-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 31 Aug 2012 03:30:28 -0700 X-Originating-IP: [124.212.98.52] X-EIP: [CP94Qbnv9FvR57AEvwt4dgjmREPRk/Ab] X-Originating-Email: [malcolm.cohen@hotmail.co.jp] Message-ID: Reply-To: "Malcolm Cohen esq." From: "Malcolm Cohen esq." To: "fortran standards email list for J3" , "sc22wg5" 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> <20120831093120.3E91535699F@www.open-std.org> In-Reply-To: <20120831093120.3E91535699F@www.open-std.org> Subject: Re: (j3.2006) (SC22WG5.4747) [ukfortran] Comments on comments on Ballot 3 on Fortran 2008 interpretations Date: Fri, 31 Aug 2012 19:30:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-OriginalArrivalTime: 31 Aug 2012 10:30:28.0773 (UTC) FILETIME=[A4116D50:01CD8763] Sender: owner-sc22wg5@open-std.org Precedence: bulk I think this will bounce from the J3/WG5 list, as I am sending via my hotmail account ... for technical reasons I cannot send from my work email when I am at home (my ISP blocks that connection). If you want to discuss further on the public list, please first forward my whole message to the list... I wrote: > 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***. Nick replied: >I still think that this is a technically bad solution, but that is a >different matter, and not something to address in an interpretation. Right. In my copious spare time I would like to be able to rewrite several large chunks of this. Actually I suspect that I will get the chance when it comes to starting integration of the interop TS. Given a more extensive rewrite, I am sure that we can get the wording more explanatory without unnecessary redundancy. I wrote: > 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. Nick wrote: >SEQUENCE is usually discouraged and not essential I wish! In bug report on new (2003/2008) features, I have users with SEQUENCE types. In fact a couple of times the bugs were only in the SEQUENCE types. >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. Correcting "immediate" design defects is reasonable, but this is from F2003, and what is more is in a very widely implemented part of 2003. Given that almost everyone has already implemented it, and user codes *ARE* using it, it is way too late to rip it out. In fact, my colleague who designed our Fortran interface to the GTK toolkit was using it. In that context, I would have to say that it is not the security aspects of the software engineering that is important, but the fact that you can do it (PRIVATE) at all! It would be a real headache for us to have to reveal to the user all the hidden implementation details which change from release to release. So yes, I am afraid that I really do think that PRIVATE components in BIND(C) types are essential software engineering tools. Even though they can be subverted, it is hardly any easier than subverting the non-BIND(C) ones anyway. I wrote: > 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. Nick wrote: >I am sorry, but that does not make sense. Yes it does. > 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. That makes zero difference in context. > 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. That makes zero difference in context. >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. ABSOLUTELY NOT. >Inter alia, are two values different That is not the bloody question. The question is whether the RELATIONAL OPERATION returns the same answers. There is NO AMBIGUITY HERE. All possible values is all possible values! I wrote' >re F03/0121: > > One might plausibly argue that we are being more helpful here than we > need to. Nick replied: >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. Well, IMO it is impossible to implement the VOLATILE semantics without it doing that, except when e.g. the Fortran and C processors are a person with pen and paper. So I think it is good advice ... but I take your point. (We'll have to continue to disagree in the C case I think! - but that is not an issue here anyway.) I don't really disagree with dropping the advice, as mentioned it is just advice. Useful advice IMO, but there we are. Cheers, -- .........................Malcolm at home.