From owner-sc22wg5@open-std.org Mon Dec 6 14:06:30 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id F22EAC178E4; Mon, 6 Dec 2010 14:06:29 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by www2.open-std.org (Postfix) with ESMTP id EB6E4C178DA for ; Mon, 6 Dec 2010 14:06:24 +0100 (CET) Received: from source ([136.162.34.13]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKTPzfzlQG0Qb2JXNM4KaplJiGSrSRq83k@postini.com; Mon, 06 Dec 2010 05:06:28 PST Received: from cf-vpn-192-168-239-37.us.cray.com (cf-vpn-192-168-239-37.us.cray.com [192.168.239.37]) by stplmr01.us.cray.com (8.14.3/8.13.8/hubv2-LastChangedRevision: 12441) with ESMTP id oB6D6KKA016613; Mon, 6 Dec 2010 07:06:20 -0600 Message-ID: <4CFCDFFA.2000303@cray.com> Date: Mon, 06 Dec 2010 07:07:06 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "John.Reid@stfc.ac.uk" , fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4350) WG5 informal ballot re Interop. TR References: <20101108175805.5B97EC178E5@www2.open-std.org> In-Reply-To: <20101108175805.5B97EC178E5@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk I am starting a 4-week informal WG5 ballot on this schedule and on N1838. Please answer these questions by 9 a.m. UK time on 7 December. 1. Is the above revised schedule acceptable? Yes. 2. Do you have any comments on N1838? Please give special attention to the UTIs. For each significant change, please provide text for a new UTI. Regarding UTI TR3, I definitely do not like the current rank-expansion scheme in the TR. The main alternate options seem to be 1 (use elem_len) and 2 (add a new element length member). I would argue that option 1 is better because: 1) From the Fortran program point of view, the length of the element of the array IS the len() of an element of the array for a character array. This is the value proposed to be used as the elem_len member in the C descriptor. 2) A character length member in the descriptor is dead weight for all types except char. And for the specific type of char, the elem_len for a single char is defined to be 1 (since the value is in units of size of char), so sticking 1 into the elem_len field provides no added information. 3) In many cases (especially in the MPI usage context) the objective is to just move a block of memory from one place to another. With option 1, there is noting special about the character len()>1 case as the appropriate number of bytes to move is the elem_len field value. With option 2, the user would have to check for type char and, for that case only, use the new field value to get the number of bytes to move per array element. (Nominally, it would be new_member*elem_len, but elem_len=1 for option 2.) This seems like an unnecessary coding complication. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101