Re: C interop and gfortran status?

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

(cc'd to fortran@)

On Mon, Feb 13, 2006 at 02:04:14PM -0700, Christopher D. Rickett wrote:
> On Mon, 13 Feb 2006, Steve Kargl wrote:
>> On Mon, Feb 13, 2006 at 11:09:41AM -0700, Christopher D. Rickett wrote:
>>> 
>>> some of the trickier issues i've been running into now have to deal with 
>>> the "C characters with special semantics" (table 15.1).  primarily, i've 
>>> been dealing with the c_null_char.  this is specified to be a character of 
>>> kind c_char, and length 1, with the value '\0'.  there was some work to 
>>> get gfortran to actually append the null char to a string literal and not 
>>> just ignore the string all together (and not to segv, which was it's first 
>>> popular action).  i haven't tried to see what happens if you were to say 
>>> something like:
>>> 
>>> 	print *, c_null_char
>>> 
>>> but this, along with what happens if it's one of the other special chars, 
>>> are things that need handled..  i personally think that the c_null_char is 
>>> the most important of them, and getting it fairly well handled should be a 
>>> good start.  
>>> 
>>> thoughts on any of this?  
>>> 
>> First, thanks for the summary.
>> 
>> The characters listed in Table 15.1 can already be included
>> in a string via the -fbackslash option except for '\0', which
>> as you noted is automatically appended to Fortran strings.
>> See primary.c(next_string_char).  I would assume the runtime
>> library does the Right Thing with these special characters, but
>> I'm not very familiar with the innards of the libgfortran.  
>> This question is probably better addressed to FX, Thomas Koenig,
>> and Jerry (or simply the fortran@ list).
>> 
> a problem i was encountering with the c_null_char is when you do something 
> like the following:
> 
> character(len=11, kind-C_CHAR) :: pPortName &
>      = C_CHAR_'PusherPort' // C_NULL_CHAR
> 
> when the expr's for the two strings are concatenated, the '\0' string for 
> C_NULL_CHAR was getting ignored, and then when the string was handed off 
> to C, the string wasn't null terminated.  i had to force it to copy 
> the null char when copying the expressions, and now, the string given to C 
> is correct (null terminated and all).
> 
> also, when reading/writing the .mod file, the c_null_char would cause it 
> to crash because the code there doesn't check for a null ptr, or null char 
> w/in the string, when calling things like strlen.   
> 

My first thought on the matter without inspecting the current 
fortran frontend code and the specifics of the C interop requirements
is to make all Fortran strings and C arrays of chars internally terminated
with a '\0' and then audit gfortran for occurences of the <string.h>
functions that may dereference a NULL pointer.  For the code above,
the concatenation operation would essentially be a NOP.

Perhaps, others on fortran@ have an opinion?

-- 
Steve