(j3.2006) C1x standard

[Van Snyder]

Malcolm Cohen wrote:
> It is perfectly obvious that if C_char is not equal to Kind('A'), i.e. that default character and C character are different, your proposal requires translation between them.
>   

I think we're concerned about two entirely different things.

My proposal aims to AVOID this in a Fortran program, not to REQUIRE it.

Are you referring to an implied requirement on a processor to convert 
whatever kind it uses for command-line arguments to kind c_char?  This 
is irrelevant to the discussion, since the only kind provided in table 
15.2 for interoperability with character type is c_char, which is the 
reason for the original discussion:  Table 15.2 only provides for kind 
c_char, get_command_argument only allows its VALUE argument to be of 
default kind, and the standard does not provide a method to translate 
between them.

The present situation, where get_command_argument requires its VALUE 
argument to be of default kind, DOES require the program to be prepared 
to translate default kind to c_char kind if it needs to be passed to a 
BIND(C) procedure, since c_char is the only kind provided for 
interoperability in table 15.2, and to anticipate how this method might 
be different in some distant future galaxy.

Without being prepared to guess what this translation might be, it is 
presently NOT POSSIBLE to pass a string gotten from get_command_argument 
to a BIND(C) procedure that has a character argument, unless kind c_char 
happens to be default kind.  It's not even possible to assign the value 
to a kind c_char variable, to pass it to a BIND(C) procedure, unless 
c_char happens to be  ISO_10646, ASCII, or default kind (see 
7.2.1.2p1(5)).  The "happens to be" part is extremely unhelpful to 
portability or future-proofing.  I have this irrational worry that if I 
were to leave this kind of time bomb in my programs, some future nerd 
will seek out my grave just to piss on it.

If get_command_argument were to allow its VALUE argument to be either 
default kind or c_char kind, then passing a value gotten with the VALUE 
argument of kind c_char to a BIND(C) procedure that has an argument of 
kind c_char, the ONLY kind the standard provides in table 15.2 for type 
character, it would NOT require translation, at least not in the Fortran 
program, which is all that's relevant to somebody reading the Fortran 
standard and writing a Fortran program, since the standard does not 
provide for interoperability of any character kind other than c_char.

> Your contention that the command line is a string of single-byte characters in all programs and operating systems,....

I never contended this, and it is not helpful to assert that I did.  
This is completely irrelevant because the Fortran standard only provides 
kind c_char for interoperable character type.  Why would I be concerned 
about wanting kinds from get_command-argument other than c_char and 
default, if I can only pass characters of kind c_char to C procedures?

Would it be helpful for me to assert that you are contending that 
default character kind is the same as the "other implementation 
dependent" type that a C processor might use for the second argument of 
the main function?  I couldn't find where the 2008 Fortran standard says 
that.  It would be irrelevant to the discussion, since one can't pass 
any character kind other than c_char to a C function.

I am contending that it is not unusual to want to pass a string gotten 
using get_command_argument to a BIND(C) procedure that has a kind c_char 
argument, since that's the only character kind the standard provides for 
interoperability.  This really has nothing to do with whether the 
command-line is a string of single-byte characters in all programs and 
operating systems, and I never contended that it does, because 
characters of kind c_char are the only kinds one can pass to a BIND(C) 
procedure.  If one really needs to get a character string from 
get_command_argument with some kind other than c_char, one can use 
default kind.  That's what generic resolution is for.  But one can't 
pass it to a BIND(C) procedure because table 15.2 doesn't provide a kind 
type parameter to do so, and the standard doesn't provide a method to 
translate it, or indeed even a reliable way simply to assign it.  
Presently, if one needs to pass a command-line argument to a BIND(C) 
procedure, one has no choice but to use default kind, and then wonder 
how to convert that to c_char (because that's the only kind one can pass 
to a C function, and the standard doesn't provide a method to translate, 
or even reliably to assign) in a portable and future-proof way.  I would 
much rather this be the responsibility of the processor, since it's much 
more likely that a processor and operating system will be in sync in 
some distant future galaxy, than a program written in the dim mists of 
antiquity, by a retired or long-dead programmer, will have anticipated 
how to do the translation consistently with the operating system in that 
distant future galaxy.  The only kind one can pass to a BIND(C) 
procedure is c_char, which is the reason to desire a VALUE argument to 
get_command_argument of kind c_char.

If it is absolutely necessary that the VALUE argument of 
get_command_argument remain only of default kind, and that 
get_command_argument not be generic, perhaps because the operating 
system and the Fortran processor might agree on some multi-byte 
character kind for command-line arguments, and default kind is that 
kind, table 15.2 needs to allow default character kind, and the C 
interoperability TS (or the next standard) needs to require a typedef in 
its .h file for a C type that will interoperate with default character 
kind, so that Fortran program units can pass strings gotten from 
get_command_argument to BIND(C) procedures, which is not presently 
possible.  In fact, it would be useful for the TS (or the next standard) 
to require typedefs for all the intrinsic types, and all the kinds for 
them that the standard requires.

If the kind of characters that the system uses for command-line 
arguments is neither c_char nor default kind, that kind ought to be 
allowed for the VALUE argument of get_command_argument, there ought to 
be a kind type parameter value named constant for it in ISO_Fortran_env, 
that kind ought to be allowed in table 15.2, assignment ought to be 
allowed for it in 7.2.1.2p1(5), and the TS (or the next standard) ought 
to require a typedef for it.

> Not to mention that C and Unix do not cover the entire computing experience.
>   

I don't remember asserting that they do, or even that this is relevant 
to the discussion.  How could this be relevant, since the Fortran 
standard provides only for interoperating with character kind c_char?  
If the kind the operating system uses for command-line arguments is 
other than c_char, there's no hope anyway of passing it to a C function, 
since c_char is the only kind provided for character type 
interoperability in table 15.2.  That's the problem that started this 
discussion:  Table 15.2 only provides for kind c_char, 
get_command_argument only allows its VALUE argument to be of default 
kind, and the standard provides no method to translate between them.  
There ought to be SOME change in the next standard to break this impasse.

>> If we want standard-conforming programs to rely on character(c_char) and 
>> default character being the same, the standard ought to just say so, and 
>> eliminate c_char as anything distinct from default character.
>>     
>
> You might well want to do that, but I will not agree with that either.  I trust I do not have to spell out my objections any further.

The paragraph I wrote does begin with "IF!"  I don't want to do this 
either.  I included this only to illustrate the absurdity of the 
suggestion that I should depend upon it, without it being so specified 
in the standard.  The suggestion that I ought to depend upon it does 
imply, however, that the command line is, and will forever remain, a 
string of single-byte characters in all programs and operating systems.