(j3.2006) C1x standard

[Van Snyder]

Bill Long wrote:
> 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?

I would expect that if the length is a constant, or determined by the C 
convention of ending with c_null, it isn't 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.
>   

Right.  In many cases, we get an interface specification on paper and a 
.so file.  No source code.  If we had source code, there might well be a 
contractual prohibitition against modifying it, or a contractual 
stipulation that if we do, that ends the provider's service liability.  
Even when we could change the source code, it's kind of far down the 
list of stuff to do, and with the NASA cutbacks, we're down to two guys 
maintaining 1/3 million lines.

>> 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 guess that's why the paragraph includes "or c_char" in several 
places.  I don't know how I overlooked that.  That makes your 
explanation pretty obvious.  Sorry for being confused.

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

They apparently haven't been updated to "some other implementation 
defined type," so the problem remains: how does one pass a characgter 
string gotten from get_command_argument to them?

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

HDF is just one example out of many, one with which I was confident 
you'd be familiar.  Would the entire list of unfamiliar packages be any 
more convincing?  You're probably aware of NETCDF.  How about HDFEOS?  
SDP Toolkit?

The "Fortran" interfaces to the HDF library were, and maybe still are, 
based upon Burkhard Burow's  cfortran macros.  Every time we start using 
a new compiler, we find that it's a real headache to use them.  Maybe 
they're based upon C interoperability now.  Either way, that raises the 
question "how do they get default character into C routines?"  Probably 
an illustration of the suggestion "it almost always worrks."

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

Why pass the length if it's (a) constant, or (b) determined by the C 
convention that the string ends with c_null?

Do you want to take these one at a time, or should I just send my 
40-page list?