(j3.2006) C1x standard

[Van Snyder]

On Thu, 2011-12-22 at 09:36 -0800, Bill Long wrote:
> 
> On 12/22/11 4:20 AM, Van Snyder wrote:
> 
> >
> > 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.
> 
> Remember that the only Fortran character that is interoperable with C is 
> KIND=c_char AND LEN=1.

I thought the TS was going to eliminate the LEN=1 restriction.  I guess
I wasn't paying close enough attention to the TS to notice that this
restriction hadn't been eliminated.  Why does it remain?

This is a bit weird, in light of 12.5.2.4p4.

>   The string that you get back from 
> get_command_argument will very likely not be LEN=1.  So you have to do 
> some sort of munching of it before sending it to a C function even if 
> the KIND is c_char.  (Like adding on the null character at the end).  If 
> you have to do that, you might as well do any kind conversion at the 
> same time.

How do I predict how to translate from default kind to c_char, in a way
that is reasonably future-proof?

> I would contend that passing the string to a C function is unusual.  Far 
> more likely, the argument is some action token that I would compare to a 
> table of options within the Fortran program, and making that table 
> default character would certainly be the natural choice.  Or the 
> argument is a file name that I later use in an OPEN statement, which 
> requires a default character kind.

Thank you for designing all of my future programs that might have to
interoperate with C.  I'll keep this idea of action tokens in mind when
I need to send a character string to a POSIX routine.  Could you
elaborate a little bit on how it would work?

I don't have a POSIX standard handy, but many of the POSIX-compliant
routines I find in my "man" pages want a "char" argument.  One of these
is "open," which I had to use because Fortran I/O didn't work for the
device my program needed to talk to (I had to invoke "select" before
"read").  I suppose I could have just converted my 1/3 million lines of
Fortran to C to avoid this problem.  Silly me, I thought 50 lines of C
would be simpler.

Many HDF and HDFEOS routines, which I'm required to use, have "char"
arguments for things like group names and dataset names.  I haven't
figured out how to replace them with action tokens.  I suppose I could
explain to people who use my software that they can't put these things
on the command line because Fortran doesn't allow me to send
command-line arguments to C functions.  They'll just laugh and point
fingers and say "You Idiot! Why are you using Fortran in the first
place?  Don't you know that Eisenhower is no longer President?"

> I'm not convinced that the case you found is sufficient motivation to 
> change the standard, especially since it would only reduce, and not 
> eliminate, the conversion work that the programmer is required to do anyway.

The standard could eliminate the other conversion work.  I had been
operating under the assumption, which I should have checked long ago,
that the TS was going to eliminate the len=1 restriction, which you used
to justify doing the other impossible-to-future-proof conversion work.

Why do we have the restriction to len=1?  I can't imagine that a
constant len other than len=1 would require a descriptor.

By the way, I have forty pages of cases of aggravation that my
colleagues have been asking me to address.

> Cheers,
> Bill
>