From owner-sc22wg5@open-std.org  Wed Jul 16 20:17:12 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom6
Delivered-To: sc22wg5-dom6@open-std.org
Received: by open-std.org (Postfix, from userid 521)
	id 44311DA74E; Wed, 16 Jul 2008 20:17:12 +0200 (CET DST)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from nmta2.jpl.nasa.gov (nmta.jpl.nasa.gov [137.78.160.215])
	by open-std.org (Postfix) with ESMTP id 18B0D393D9
	for <sc22wg5@open-std.org>; Wed, 16 Jul 2008 20:16:58 +0200 (CET DST)
Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111])
	by nmta2.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6GIGtCD026499
	for <sc22wg5@open-std.org>; Wed, 16 Jul 2008 11:16:56 -0700
Received: from mprox3.jpl.nasa.gov (mprox3.jpl.nasa.gov [137.78.160.171])
	by xmta3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6GIGstK024666
	for <sc22wg5@open-std.org>; Wed, 16 Jul 2008 11:16:54 -0700
Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57])
	(authenticated bits=0)
	by mprox3.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id m6GIGqst012421
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <sc22wg5@open-std.org>; Wed, 16 Jul 2008 11:16:53 -0700
Subject: Re: (j3.2006) (SC22WG5.3584) OPTIONAL arguments and C interop
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
To: sc22wg5 <sc22wg5@open-std.org>
In-Reply-To: <20080716151703.5BDC9D9F76@open-std.org>
References: <20080716151703.5BDC9D9F76@open-std.org>
Content-Type: text/plain
Organization: Yes
Date: Wed, 16 Jul 2008 11:16:52 -0700
Message-Id: <1216232212.13521.25.camel@math.jpl.nasa.gov>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) 
Content-Transfer-Encoding: 7bit
X-Source-IP: math.jpl.nasa.gov [137.79.7.57]
X-Source-Sender: Van.Snyder@jpl.nasa.gov
X-AUTH: Authorized
Sender: owner-sc22wg5@open-std.org
Precedence: bulk


On Wed, 2008-07-16 at 09:47 -0500, Bill Long wrote:
> A side effect of this design is that OPTIONAL and VALUE cannot be both
> specified for a particular dummy argument.

Bill:

I don't understand this problem.

I would think that processors could use their Fortran conventions for
argument forms that don't exist in C, i.e., assumed-shape arrays,
optional arguments, and optional+value arguments.  The TR would specify
functions or structs to access and create such arguments.  Preferably
functions, so that vendors can provide them according to their Fortran
conventions, instead of changing their Fortran conventions to conform to
structs specified by the TR for the BIND(C) case.

Van