From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Dec 8 13:17:18 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 72CBC356976; Sat, 8 Dec 2012 13:17:18 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 2658 seconds by postgrey-1.34 at www5.open-std.org; Sat, 08 Dec 2012 13:17:09 CET Received: from userp1050.oracle.com (userp1050.oracle.com [156.151.31.82]) by www.open-std.org (Postfix) with ESMTP id 7D65A3568BD for ; Sat, 8 Dec 2012 13:17:08 +0100 (CET) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by userp1050.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB89YD1R014151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 8 Dec 2012 09:34:14 GMT Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB89YBLP005470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 8 Dec 2012 09:34:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qB89YAWM015877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Dec 2012 09:34:10 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qB89Y9lx013974 for ; Sat, 8 Dec 2012 03:34:10 -0600 Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Dec 2012 01:34:09 -0800 Message-ID: <50C30970.7060101@oracle.com> Date: Sat, 08 Dec 2012 01:33:36 -0800 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:6.0) Gecko/20110814 Thunderbird/6.0 MIME-Version: 1.0 To: WG5 Subject: Re: WG5 letter ballot 5 on Fortran 2008 interpretations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userp1040.oracle.com [156.151.31.81] Sender: owner-sc22wg5@open-std.org Precedence: bulk This is the fifth WG5 vote on a set of draft interpretations for Fortran 2008. They have all been approved in a J3 letter ballot. The following Fortran 2008 interpretations are being balloted: Yes No Number Title -Y- --- F08/0040 MOVE_ALLOC for coarrays -Y- --- F08/0074 Implicit type in BLOCK construct -Y- --- F08/0077 Function references as variables in DATA statements --- -N- F08/0078 Are the IEEE values +0 and -0 distinguished -C- --- F08/0079 NAMELIST and type specification -Y- --- F08/0080 Array constructors with polymorphic values --- -N- F08/0081 Deallocation error handling -Y- --- F08/0082 Generic identifier and dtv arguments ------------------------- F08/0078 The distinction between +0 and -0 is a fundamental component of the model of floating-point arithmetic defined by IEC 60559. Therefore, I believe the proposed interpretation is flawed. Nonetheless, I would change my vote to yes if a few edits were made. The first line of Note 4.8 [54:18+] is "On a processor that can distinguish between 0.0 and -0.0". I would have that replaced with "On a processor that distinguishes between 0.0 and-0.0". The description of the SIGN intrinsic in clause 13.7.153 includes the phrase "if the processor cannot distinguish between positive and negative real zero". I would have that phrase replaced with "if the processor does not distinguish between positive and negative real zero". Any processor that implements IEEE_COPY_SIGN "can" distinguish between +0.0 and -0.0. ------------------------- F08/0079 C The phrase "kind parameters of the declared type" in the proposed edit appears to be unnecessary. I see no way to specify the declared type of a namelist group object without also specifying the values of the kind type parameters of the declared type. I hope the requirements for "prior specification" will be revisited in the next revision of the standard. ------------------------- F08/0081 N I think making it processor dependent whether or not finalizers are executed when a DEALLOCATE statement signals an error condition will create conditions that will lead to corrupted data structures. The only safe action for a program that detects an error condition during execution of a DEALLOCATE statement where a finalizer might be invoked will be to terminate execution.