(j3.2006) Get_Command_Argument

[Craig Dedo]

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On Behalf Of Van
> Snyder
> Sent: Friday, December 16, 2011 02:43
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) Get_Command_Argument
> 
> Malcolm Cohen wrote:
> >> What translation?  C_char to c_char?
> >>
> >
> > The translations I pointed out in my previous message.
> >
> > I know some like to think the whole world could make do with ASCII, but that is
> not the case.  The "real" command line is not necessarily going to be C char, and
> that means translation if you want a C char version.
> >
> > You seem to think we know what translation you want and so "it will just work 20
> years from now".  It just ain't so.
> >
> 
> I'm assuming that if get_command_argument(i,value) were to provide the VALUE
> argument as a kind c_char variable, it would be the same that a C main function
> would get from argv[i].  If that's actually naive, then I guess I'll need more
> explanation why there would be translations involved, for which my programs would
> be responsible.
> 
> I don't have a C standard at hand, but my K&R book, on page 115, defines argv as
> 
>   char* argv[]
> 
> Could a C programmer safely assume that argv[] is "char*"?

	No.  Please read ISO/IEC 9899:1999, clause 5.1.2.2.1, ALL of it CAREFULLY.  Here
are some quotes.

>From p1:
[Begin quote]
The function called at program startup is called main.  The implementation declares no
prototype for this function.  It shall be defined with a return type of int and with no
parameters:
	int main (void)  {/* ... */}
or with two parameters (referred to here as argc and argv, though any names may be used,
as they are local to the function in which they are declared):
	int main (int argc, char *argv[])  {/* ... */}
or equivalent; or in some other implementation-defined manner.
[End quote]

That last phrase contains the weasel words that allows a C compiler to do whatever it
likes, as far as program startup arguments go, and remain fully standard-conforming.

Thus, a standard-conforming C compiler could quite legally declare main to be:
	int main (int argc, wchar_t *argv[])  {/* ... */}

This would be useful in a C compiler intended for use in a culture that extensively uses
non-Latin characters.  E.g., consider a C compiler in use in areas that use the Arabic
script or the Han ideographs.  The users of the programs may wish to pass arguments to the
programs at startup using those character sets.

>From p2, third list item:
[Begin quote]
If the value of argc is greater than zero, the array members argv[0] through argv[argc-1]
inclusive shall contain pointers to strings, which are given implementation-defined values
by the host environment prior to program startup.  The intent is to supply to the program
information prior to program startup from elsewhere in the hosted environment.
[End quote]

Again, a use may wish to pass to a program values using the Han ideographs.

We can no longer afford to be anglo-centric in our thinking.  People in other cultures
can, and do, use character sets other than ASCII.

> Could a Fortran programmer safely assume that C type "char" is equivalent to
> Fortran type CHARACTER(kind=c_char)?

	Yes.  See ISO/IEC 1539-1:2010, clause 15.2.2p2 and Table 15.2.

> If those assumptions are both safe, what's the problem with allowing
> get_command_argument to return a VALUE argument of kind c_char, at least allowing
> one to pass it along to a C function that expects the same value it would have
> gotten from its own main function's argv?
> 
> Does the current C standard actually define argv with a type different from char?
> If so, the Fortran standard ought to provide a kind, in ISO_C_Binding, that's
> equivalent, and allow get_command_argument to return a VALUE with that kind.

	No.  As I pointed out above, a standard-conforming C implementation may define
argv to be something other than char, e.g., wchar_t.

Sincerely,
Craig T. Dedo
17130 W. Burleigh Place
P. O. Box 423                         Mobile Phone:  (414) 412-5869
Brookfield, WI   53008-0423    E-mail:  <craig at ctdedo.com>
USA
Linked-In:  http://www.linkedin.com/in/craigdedo