Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28994 Discussions

Memory error using character(*) and DLLs

Roberto_Sartori
Beginner
498 Views
Hi, I'm using intel fortran compiler 10.1 and VS2005 and I currently have a problem in using a fortran DLL precure. Take a look on this simply example:

SUBROUTINE PROVA(i,msg1,msg2)
!DEC$ ATTRIBUTES DLLEXPORT::PROVA
INTEGER :: i
CHARACTER(*) :: msg1,msg2
END SUBROUTINE

msg1 and msg2 results as corrupted adresses when debugging into this dll api, no matter how I define the character vectors that i pass as arguments (character(*), character(10), ... ). What is my problem? is the argument type CHARACTER(*) the problem? Is this related to the DLL call convention?
Please notice that if I use this subroutine

SUBROUTINE PROVA
2(i,msg1)
!DEC$ ATTRIBUTES DLLEXPORT::PROVA2
INTEGER :: i
CHARACTER(*) :: msg1
END SUBROUTINE

everything works fine and msg1 contains the correct argument string. But if I use

SUBROUTINE PROVA3(msg1,i)
!DEC$ ATTRIBUTES DLLEXPORT::PROVA3
INTEGER :: i
CHARACTER(*) :: msg1
END SUBROUTINE

with msg1 BEFORE i the problem appear again and both msg1 and i are corrupted...

Hope to recive help about this problem! thanks a lot
Roberto
I thought that is there could be a
0 Kudos
2 Replies
Steven_L_Intel1
Employee
498 Views
You haven't shown how you call PROVA. If calling from a language other than Fortran, you need to make sure that the string lengths are passed in the proper position.

However, we did have a bug with DLLEXPORTed character variables that is fixed in last week's 10.1.014 update, so please try that and let me know what you find.
0 Kudos
Roberto_Sartori
Beginner
498 Views
Thanks for your answer, I catched the problem: my DLL was built with 'CVF' calling convention wich expects the lengths of the character strings arguments immediatly after their address while while my application was built with 'default' calling convention wich puts the lengths of the character strings at the end of the parameter list. This means that the size of the call stack is the same for both 'caller' and 'called' routine and so the linker find no errors but at runtime the arguments are obviously misunderstanded.

roberto
0 Kudos
Reply