From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed May 27 03:07:56 2015 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 32C76358854; Wed, 27 May 2015 03:07:56 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 8747E3586DF for ; Wed, 27 May 2015 03:07:51 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id t4R17g3j023161 (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO); Tue, 26 May 2015 18:07:45 -0700 Subject: Re: (j3.2006) (SC22WG5.5508) [ukfortran] Assignment to ero-sized strings and arrays From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: fortran standards email list for J3 Cc: sc22wg5 In-Reply-To: <20150527002750.5E217358852@www.open-std.org> References: <20150526222707.E035535859B@www.open-std.org> <20150526224650.5BCED3586DF@www.open-std.org> <20150527002750.5E217358852@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Tue, 26 May 2015 18:07:42 -0700 Message-ID: <1432688862.19025.241.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Wed, 2015-05-27 at 09:27 +0900, Malcolm Cohen wrote: > >This seems to need an interp. > > I disagree. There is no doubt as to the intention. No-one is getting this > wrong. Walt had this discussion with Robert Corbett earlier, and it can be read > (admittedly with difficulty) as we obviously intended. > > It's certainly a candidate for editorial improvement sometime. Though since > there are newer features with confusing wording, or even straight-out technical > defects, I would not rate this as high priority. It's much more important to > get right the things that vendors and users are going to be reading and trying > to understand. Can we at least move the last sentence of 7.2.1.3p1 somewhere after 7.2.1.3p3? > Cheers,