(j3.2006) C1x standard

[Bill Long]

On 12/22/11 5:40 PM, Van Snyder wrote:
>
> 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?
>

The LEN=1 restriction does not apply if the argument is passed by 
descriptor. How else do you propose that the length should be 
communicated to the C function?   If the C side formal parameter is 
coded as an array of characters, and not as a "string", then it will be 
OK.  But I suspect none of the routines you want to call are like that.

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

Applies to Fortran - Fortran calls.  C does not have a data type 
analogous to Fortran character with len > 1.


>
> 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.

Checking the man page for pxfopen, I see some arguments of type 
character.  Certainly this is Fortran default character, since these 
interfaces are from the f77 era when there was no other kind.

>
> 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?"
>

Not clear how this matters if you are using the Fortran interfaces to 
the HDF library.


>> 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.

Because it requires the length to be passed somehow.  A very long time 
ago we rejected the "hidden argument" scheme that some Fortran compilers 
use internally.  Such a scheme would not help in your desire to interact 
with C functions not written to expect these extra arguments. The 
descriptors provide a solution.

Cheers,
Bill


-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101