(j3.2006) Get_Command_Argument

[Van Snyder]

On Wed, 2011-12-14 at 19:15 -0800, Malcolm Cohen wrote:
> Van Snyder asked:
> >Is this legal?
> 
> [non-default-integer NUMBER argument to GET_COMMAND_ARGUMENT]
> 
> (the answer being clearly not)
> 
> and
> > Should it have been legal in the latter two cases?
> 
> Bill Long replied:
> >I don't think so.  We very often require "default" kinds and it would be
> >tedious to everywhere insert "or kind=c_int", etc.  Since it is very
> >unlikely that these inequalities would be true for a currently relevant
> >compiler, it also seems unhelpful.
> 
> I take the opposite viewpoint: we have been removing default kind requirements 
> when they are not meaningful, e.g. in various i/o statements, and I see 
> absolutely no reason why GET_COMMAND_ARGUMENT should not accept an 8-bit 
> integer, or for that matter any integer capable of representing the argument 
> number.  It is just an annoyance for the user to have to put INT around it.

How about the case of the character argument having kind == c_char in
case c_char /= kind('A')?  Should we think about allowing that too?  We
allow default character kind, ASCII kind, or ISO 10646 kind for internal
files.

I'm not advocating that we change every place that says "default
character kind" to "default, ASCII or ISO 10646 character," but
"get_command_argument" and "get_environment_variable" seem like
reasonable places to allow at least character(c_kind), no matter what
c_kind is.  These procedures are, after all, fundamentally C procedures
that have been incorporated into essentially every operating system.

Maybe it would be reasonable as well to allow the file name in OPEN and
INQUIRE statements to be of kind c_char.

I can't think of any more places right now.  Maybe that's the entire
list.

> Cheers,