Character string bindings, windows, linux compatability

[nbunderson]

Hi I'm trying to write bindings for a c library that will compile in both Linux (XE 2011) and Windows (10.0.025). I have many issues that I can't seem to find help with but let me start with this one: when passing a character array windows will compile if i declare as:

CHARACTER(kind=gchar, len=*):: stock_id

linux will compile if I declare as

CHARACTER(kind=gchar), dimension(*):: stock_id

neither will compile if I switch them. Is this because my windows compiler is old or because of some Linux - windows difference? Thanks in Advance,

Nate

INTERFACE
FUNCTION gtk_button_new_from_stock(stock_id) bind(C,name="gtk_button_new_from_stock")
USE GTK_CONSTANTS, ONLY: INTPTRKIND, gchar
IMPLICIT NONE
INTEGER(KIND=INTPTRKIND):: gtk_button_new_from_stock
CHARACTER(kind=gchar), dimension(*):: stock_id
ENDFUNCTION gtk_button_new_from_stock
ENDINTERFACE

[IanH]

It is because your Windows compiler is old. Did Intel Fortran version 10.0 even have C interoperability? If it did, I recall there were issues with passing of characters to BIND(C) functions in earlier Intel Fortran versions.

Your "linux" declaration is more correct - only character scalar or array entities of (LEN=1,KIND=C_CHAR) are interoperable. I don't think earlier versions of the compiler picked that up.

Why not take a C_PTR as the return type?

[Steven_L_Intel1]

What exactly is the error message you get? 10.0 did have C interoperability features, but had many errors. Nonetheless, the array of single-byte characters should work in both compilers. I assume that "gchar" evaluates to 1.

[nbunderson]

Below I've included the relevant definition, routine call, interface and error.

!**************************************************************************
CHARACTER*30, PARAMETER :: GTK_STOCK_FIND = "gtk-find"//char(0)

INTERFACE
FUNCTION gtk_button_new_from_stock(stock_id) bind(C,name="gtk_button_new_from_stock")
USE GTK_CONSTANTS, ONLY: INTPTRKIND, gchar
IMPLICIT NONE
INTEGER(KIND=INTPTRKIND):: gtk_button_new_from_stock
CHARACTER(KIND=gchar),dimension(*):: stock_id
ENDFUNCTION gtk_button_new_from_stock
ENDINTERFACE

button = gtk_button_new_from_stock (GTK_STOCK_ADD);

!**************************************************************************

I didn't realize this before but if I simply remove the PARAMETER attribute everything works.

!**************************************************************************
CHARACTER*30 :: GTK_STOCK_FIND = "gtk-find"//char(0)
!**************************************************************************

Sorry I didn't check that before. I'm not sure why I can't do that but I don't mind dropping PARAMETER

On another topic, I guess I should buy a new windows compiler eh? If it's known to have a lot of interoperability issues then maybe it's the cause of a lot of my headaches :).

Nate

[nbunderson]

forgot to include the error message...

Error 2 Error: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [NAME] sourceviewwindow.f90 882

[nbunderson]

A few last things, in the above post I grabbed the wrong variable, should be:

CHARACTER*30 :: GTK_STOCK_ADD = "gtk-add"//char(0)


Also, even if I leave the character string as a parameter the code compiles if I trim the variable

!************************************************************
button = gtk_button_new_from_stock (trim(GTK_STOCK_ADD));
!************************************************************
WORKS



also if you hard code the string but forget the null termination

!********************************************************
button = gtk_button_new_from_stock ("gtk-add")
!********************************************************
DOESN"T WORK SAME ERROR


!********************************************************
button = gtk_button_new_from_stock ("gtk-add"//char(0))
!********************************************************
WORKS

[Steven_L_Intel1]

This all works correctly in 12.0.