From owner-sc22wg5@open-std.org Mon Dec 8 18:57:29 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 94BCBC178E5; Mon, 8 Dec 2008 18:57:29 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from nspiron-2.llnl.gov (nspiron-2.llnl.gov [128.115.41.82]) by www2.open-std.org (Postfix) with ESMTP id C99A3C178E4 for ; Mon, 8 Dec 2008 18:57:27 +0100 (CET) X-Attachments: None Received: from cyrus2.llnl.gov ([128.15.97.105]) by nspiron-2.llnl.gov with ESMTP; 08 Dec 2008 09:57:26 -0800 From: Aleksandar Donev Organization: LLNL To: WG5 Subject: Re: (j3.2006) (SC22WG5.3752) Ballot on the technical content of the TR Date: Mon, 8 Dec 2008 09:57:25 -0800 User-Agent: KMail/1.9.4 References: <20081127193527.EF00DC178D9@www2.open-std.org> <20081208024650.76234C4596C@www2.open-std.org> In-Reply-To: <20081208024650.76234C4596C@www2.open-std.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200812080957.26217.donev1@llnl.gov> Sender: owner-sc22wg5@open-std.org Precedence: bulk On Sunday 07 December 2008 18:46, Jim Xia wrote: > 2.) Fortran descriptors > Although Fortran descriptors are used when passing assumed-shape > arrays, pointer arrays and allocatable arrays by many vendors, they > are however not universally used by all vendors. They are by all existing vendors that still sell compilers, especially=20 those that intend to implement F2008 or any TRs or any new features=20 what-so-ever. Besides, EVERY new feature ads implementation burdens,=20 that is what they are for! We try to minimize the effort, but it cannot=20 be made zero. >=A0Furthermore allowing > updates on Fortran descriptors from C programs will likely cause > safety issues and also be problematic in consistency check by some > vendors. =A0This becomes a sure way to introduce bugs difficult to > diagnose. I do not understand this. You don't want a descriptor TR at all or not?=20 You want something that is "safe"---can you propose such a design=20 please? I find it impossible to imagine how C can pass things to=20 =46ortran by descriptor without being allowed to modify the descriptor???=20 Perhaps you have something else in mind, but the above does not make=20 sense. > =A0These features are of more urgent and important nature than the > OPTIONAL or the descriptor features in TR 29113.=20 OK, I agree. > Therefore it is=20 > more desirable to devote effort and study to these features in a > separate TR. The sure way to DELAY them would be to restart the process yet once=20 again. When will we learn that revisiting past decisions 100+ times is=20 a waste of time?!? Best, Aleks =2D-=20 Aleksandar Donev, Ph.D. Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory High Performance Computational Materials Science and Chemistry E-mail: donev1@llnl.gov Phone: (925) 424-6816 Fax: (925) 423-0785 Address: P.O.Box 808, L-367, Livermore, CA 94551-9900 Web: http://cherrypit.princeton.edu/donev